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Abstract 


This  collection  of  docuine;its  describes  the  existing  Feature  Exchange.Language  (FEL)  as 
it  is  impleniented  in  the  prototype, Melligent  Maduning  Workstation  (HyTW).  The  origi¬ 
nal  design  of  FEL  is  described,  therFEL  interface  to  several  IMW  subsystems  (Planning, 
Modeling,  and  Holding)  is  explained  in  considerable  detdl/  and  the  implementations 
for  bpth  die  Sun  Unix  C++  and  the  TI  Explorer  Lisp  environments  are  explained. 


Executive  Suminar}'- 


The  Feature  Exchange  Language  (FEL)  has  been  designed  as  a  language  for  communi¬ 
cating  messages  in  a  distributed' environment.  \ 


Design  Feature-1:  FEL  was  designed  to  make  parsing-and  generation  siniple.  The  as¬ 
sumption  was  that  possibly  many  different  computing  platforms  would  require  an  FEL 
inte^reter, 


Design  Featufe-2:  It  was  assumed  that  FEL  could  tie  together  processes  runnihg.on  one 
mac^ne  or  many,  and.  therefore  FEL  was  designed  to  represent  the  sender>  receiver(s) 
and  other  information  that  could  be  i;seful  in  message  transport.  N 


Desigri  Feature-3:  Features  were  diosen  as  tire  objects  that  should  be  communicated. 
Each  feature  has  a  name  and  a  set  of  built  in  parameters  that  go  with  it.  ^ 

Design  Feature-4:  Each  ^ntence  of  FEL  has  a  verb  that  specifies  how  a  message  should 
be  interpreted  by  a  particular  receiver.  \  There  has  been  a  strong.effort  to  keep  the  num¬ 
ber  of  verbs  tp  a  minimum,  allowing^essage  variations  to  be  specified  in  Ae  feature- 
lists.  Note:  verbs  are  overlbadedjjKne  sense  that  each  receiver  can  interpret  a  message 
in.a  way  most  nieaningfulrtoTf! 

Design  Feature-5:  EEL  was  designed  to  represent  complex  message  exchanges  between 
distributed  parties.  >^or  example,  verb-tense  and  a  dialogue  name  are  used  to  open, 
keep-track-of,  and  close^a  given  dialo^e.  In  this  way,  it  is  possible  to  essentially  pro¬ 
cess  multiple  messages  afohce:  every  receiver  can  act  as  a  server. 


This  document  explains  how  thes^eatures  were  in  fact  implemented  and  then  how 
FEL  was  used  in  various  applications: 


3D  Modeler  Updates  and  Queries 
Planning  Requests  for  Information 
Holding  Expert  Queries  and  Answers 


M 


We  believe  that  this  language  is  a  good  first  step  towards  the  development  of  a  messag¬ 
ing  system  that  can  easily  integrate  and  coordinate  software  modules,  especially  those 
found  in  manufacturing  applications. 


There  is  further  work  that  we  believe  is  necessary  to  have  a  truly  useful  manufacturing 
language. 


•  Including  feature  definition  as  part  of  the  language 

•  Extending  work  on  dialogue  management 

•  Supporting  negotiation  and  contract  management  as  part  of  an  FEL  implementation 
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Abstracb 

This  dcxument  is  the  original  (preliminary)  design  specification  for  FEL  (Feature 
Exchange  Language). 

A  detaded  description  of  the  original  syntax  of  FEL  sentences  is  given,  as  well  as  a 
^tailed  overview  of  the  semantics  of  many  of  the  verbs  and  attributes  of  the  language. 
The  current  implementation  of  FEL  was  motivated  by  this  document.  Some  of  &e 
advanced  language  features  described  here  have  yet  to  be  implemented,  but  all  of  the 
basic  features  of  the  language  are  employed  in  the  existing  prototype  of  the  IMW 
(Intelligent  Machining  Workstation). 
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1.  Background  Information 

The  Melligent  Machining  Workstation  includes  many  deferent  subsystems,  which 
must  communicate  wth  each  other.  Each  subsystem=h^  its  own  features,  parameters 
and  capabilities;  the  Feahure  Exdtahge  L^gUage  (FEE),  specifies  a  simple,  yet 
unified,  approadi'for  exAahgihg  this  ihforriiation. 

At  the  same  time,  FEL  must  cope  with  part  descriptions  or  product  definitions.  The 
spirit  of  lan^age  famiily  PDbl/GMAP/MFGMAP/PDES  is  to  go  beyond  geometry 
and  encomp^s  process' into  the  part  descHption.  Since  MFGMAP  is  meant  to  be  our 
subset  of  GMAP  it  is  important  fo  keep  the  same  flavor  to  it  ~  it  must  specify  more  than 
just  geometiy. 

Requirements  for  both  product  definition  and  control  information  have  two  major 
parts:  a  command  and  m^y- parameters.  The  parameters  can  be  collected  together  to 
desCTibe  the  objects  that  we  wish  to  manipulate'  —  these. objects  are. called,  feature  lists. 
Each  of  these  feature  lists  describes  a  collection  of  attributes  and  values  that  constitute  a 
feature  definition;  in  some  ca^es,  it  is  more  convenient  to  think  of  the  feature  lists  as  de¬ 
scribing  objects  or  nouns. 


2.  The  Featiue  Exchange  Language  (FEL) 

Since  we'Have.  uiiified  the  goal  of  these  two  languages  into  one  way  of  desaibing  and 
exchanging  features  of  parts  and  prbces^s,  we  have  decided  to  rename  it  the  "Feature 
Excharige  Langiiiage."  The  top-level  syntax  of  this  language  is  described.as: 

Sentence::*  "(" <Verb><Feature_Lists> ")"  I  "("")" 

Feature_Lists::=  <Feature_List>  <Feature_Lists>  I 

<Attrib>  <Feature_Lists>  I  nil 

The  language  syntax  specifies  that  any  command  can  have  any  number  of  feature  lists. 
This  allows  verbs  to  be  written  such  that  they  can  take  any  number  of  objects  (i.e.,  fea¬ 
ture  lists)  as  ^^ments.  It  is  also  possible  to  add  additional  feature  lists  that  could 
desaibe  where''the  message  is  sent>  and  notes  that  might  be  useful  for  debugging  and 
user  displays. 


3.  The  FEL  Verb  Breakdown 

In  FEL  there  are  five  different  types  of  each  verb.  These  verb  styles  denote  state  transi¬ 
tions  in  a  dialogue  between  two  subsystems.  The  state  transition  tables  for  these  dia¬ 
logues  are  discussed  in  a  later  section. 

(1)  Present  -  Command  to  go  to  new  state 

(2)  Active  -  In-process  of  going  to  new  state 
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(3)  Past  ~  Have  reached  new  state 

(4)  Not_Past  -  Have  not  and  will  not  reach  the  desired  state 

(5)  Stop_Active  ~  Terminate  an  active  state 

These  verbs  define  transitions  in  a  simple  state  network.  The  "imperative  verbs"  are 
eqnivalent  to.  the  "present  verbs"  ahd-the  "deciMative"  verbs  Me.split  into  "active"  and 
"past"  verbs.  The  "interrogative"  verbs  are  still  covered  by  Ae  "present  verbs"  by 
choosing  verbs  that  request  information. 

There  are  also  two  control- oriented  verbs  (Not_Pi^t  and  Stop_Actiye).  In  any  type  of 
error  situation  it  is  necessaiy  to  communicate  tlfat  an  action  has  not  been  accomplished. 
On  the  other  hand,  it  may  be  necessaiy  to  abort  an  ongoing  a,ctipn,  because  of  some 
external  influences  or  new  information.  This  will  be  discussed  further  in  the  section  on 
communication  states. 

The  result  is  that  each  commimication  has  a  beginning,  m  optional  middle  md  an  end,. 
For  example,  one.interchange  of  verbs  could  be: 


Message  Out  from  Source:  —>  M^e 

Message  Received  at  Source:  Making  <- 

Message  Received  at  Source:  Made  <- 

The  lexical  analyzer  can  be  responsible  for  marking  the  tokens  as  present,  active  or  past. 
This  scheme  will  work  fine  for  most  verbs,  but  may  cause  some  confusion  for  irregular' 
verbs,  as/  "is",  ’being",  and  "was."  There  are  two  solutions  to  this  problem.  We  can 
introduce  a  special  characters,  such  as,  In  this  case,"is!",  "is<"  and  "is=".  Or 

simply,  we  could  choose  built-in  verbs  with  reasonable  conjugations. 

Verbs::=  <Present>  I  <Active>  I  <Past>  1  <Not_Past>  I  <Stop_Active> 

Recommendation:  There  are  advantages  to  using  English  verbs  and  conjugations, 
because  they  can  be  readily  paraphrased  into  full  English  sentences  for  the  human 
interface. 

A  design  goal  for  FEL  is  to  make  its  verbs  and  verb-types  orthogonal.  That  is,  every 
verb  should  be  able  to  be  put  into  every  form.  This  should  be  true  no  matter  what  verb 
classification  scheme  is  chosen. 
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4.  Built-In  Verbs 

In  generd,  the  verbs  are  meant  to  desaibe.actions  on  feature  lists  ^  well  as  methods 
^d  states  pf  negptiation.  Fortimately,  very^few  verbs  will  go  a  long  way,  bjecause  most 
of  the  final  actions  depend  on  the  contents  of  the  feature  lists.  What  follows  is  a  nearly 
complete  list  of  verbs  that  wfil  be  needed  fpr  the  IMW. 

Negptiation  Verbs: 

Offer  i  Offering.  1  Offered  I  NotJDffered  I  • 

Stop_C)f^ferihg 

Accept  I  Accepting  1  Accepted  I  Not_Accepted 
Cancel  I  Canceling  I  Canceled  I  Not_Canceled 

Database  Verbs: 

Define  1  Defining  I  Defined  I  Not_Defined 
Update  1  Updating  I- Updating  INotJJpdated 
Delete  I  Deleting  1  Deleted  1  NotJDeleted 
Get  I  Getting  r  Got  J  Nbt_Gotten 

Machining  Verbs: 

Make  I  Making  I  Monitoring  i.  Made  1  Monitored  I  pp.  26-27 

Not_Made  |  Not_Monitored  I 
Stop_Monitoring  I  Stop_Making 

Inspect  I  Inspecting  I  Inspected  I  ]Sfot_Inspected  I 
Stopjhspecting 


Defined  Example 
pp.  24-25 

pp.  21-23 
p.27 

p.26 
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5.  Verb  Definitioiw 

Offer;  This  message  verb  is  a  command  to  fill  in  ^ggested  vdues  in  a  feature  fet.  For 
example,  if  the  planner  wishes,  to  ask  the  oittog  expert  for  su^ested  speeds  and  feeds 
fiten  &e  planner  could  use  this  verb. 

Accept  This  message  verb  agrees  on  negotiated  values  passed  between  two  systems. 
It  has  the  effect  of  si^ng  a  contract  between  the  two  systems  after  an  offer  has  been 
made.  Eventually,  we  may  impose  sanctions  on  systems  that  wish  to  break  contracts. 

Cancel;  This  message  verb  is  the  only  way  to  break  a  contract  that  has  been  negotiated 
between  two  subsystems.  If  it  is  issued,,  then  it  is  assumed  that  the  system  breaking  the 
contract  is  subject  to  the  sanctions  of  the  coritfact. 

Define;  This  message  verb  allows  one  subsystem  to  pass  a  feature  list  to  another  sys¬ 
tem,  because  it  is  known  a  priori  that  the.  information  is  needed.  For  example,  fiiis  mes¬ 
sage  type  would  be  used  to  distribute  part  model  information. 

Update;  this  message  verb  allows  one  subsystem  to  update  remote  copies  of  a  feature 
list.  This  can  be  used  only  if  the  remote  copies  of  the  feature  list  belong  to  the  source  of 
this  message,  otherwise  there  is  a  violation  of  data  security. 

Delete;  This  message  verb  allows  one  system  to  delete  another  system's  feature  list. 
This  verb  cannot  be  used  to  delete  pending  contracts,  though  once  contracts  have  been 
completed,  then  this  verb  can  be  used. 

Get  This  message  verb  allows  one  system  to  get  a  feature  list  from  another  system. 
Ownership  of  the  feature  list  remains  with  the  soiu-ce  of  the  information. 

Make:  This  message  verb  commands  the  system  to  carry  out  actions  that  will  make  the 
defined  features  in  the  extern^  world.  In  other  words,  this  verb  would  command  the 
system  to  machine  a  part,  rather  than  manipul<iting  internal  information. 

Inspect:  This  message  verb  commands  the  system  to  carry  out  actions  that  would  in¬ 
spect  the  external  world.  In  other  words,  after  a  part  is  machined,  this  verb  could  be 
used  to  inspect  the  final  result. 
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6.  Representing  Parameters  as  Feature  Lists 


The  primmy  problem  area  for  both  MFGMAP  and  SML  was:how  to  represent  many; 
m^y  ramplex  parameters.  SML  chose  a  representation  known  as  Working  Elements 
based  on  work  done  at  NBS.  This  scheme  is  essentially  named  structures,  wWdi  can  be 
nested  into  hierarchies.  We  represent  these  hiercffchies.  by  explicitly  naming  &e  nodes 
of  the  hier^chy  ^d  then  list  brandies  of  the  hier^chy  as  its  p^s  with  "Has_Parts." 


Example  Feature  List: 


( 


(Name  PL^Cylihder) 

(Type  Cylinder) 

(Length  Sinches) 

(Radiiis  Sinches) 

(Has_Parts  (CX_Holel  CX^H61e2  CX.HoleS))) 


This  example  shows  how  the  plari^r  might  describe  a  cylinder  with  three  subparts  as  a 
feature  list.  Also  nested  featine  lists  do  not  need  to.  define  a  , proper  hierarchy.  For 
example,  MFGMAP  applications  make  it  necessa^  to  represent  loops  for  edges  and 
faces. 


To  make  parsing,  as  simple  ^  possible,-  dl  spedal  s)rinbols  have  been  removed  and  the 
syntax  is  essentially  equivalent  to  association  lists  in  LISP.  However,  the  basic  structure 
is  identical  to  NB^type  work  elements. 

One  problem  with  these  feature  lists  is  that  all  the  different  attributes  have  to  be 
understood  by  each  subsystem  and  yet  they  remain  ad  hoc.  Therefore,  as  an  area  of 
development,  we  need  to  further  systematize  the  attributes  and  consider  computational 
devices  for  dynamically  inb-odudng  new  attributes. 
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7.  Feature  List  S3nitax 

A  partial  syntax  description  of  a  feature  list  is: 


Feature_List::= 

Attrib_List::= 

Attrib::= 

Value::= 

Dimensions::= 

Units::= 

Rates::= 

Rate_Units::= 

Value2::= 


Val_List::= 

List::= 


”("  <Attrib_Ost>  ")■* 

"("  <Attrib>  <Value>  ")"  <Attrib_List>  i  nil 

<Alphabetic+_>  I  <Alphabetic+_>  <Alph^mneric+_> 

<Attrib>  I  <Integer>  I  <Floating  Point>  I  <Dimensions>  I 
I  <Rates>  I  <String>  I  <Iist> 

<Integer>  <Units>  I 
<Floating,Point>  <Units> 

"cm"  I  "mm"  I  "inches"  1  "mils"  I  "sec"  I  "min" 

"radians"  I  "degrees"  I  nil 

<integer><Rate_Units>  I 
<Floating_Poiht>  <Rate_Uhits> 

"rpih"  I  "rps"  I  "ips"  I  "ipm"  i  nil 

<Attrib>  I  <ihteger>  1  <Flpating  Poiht>  !  <Dimensions>  I 
.1  <Rates>  I  <String> 

<Value2>  I  <Value2>  <Val_Iist> 

'!("  <VaLList> ")" 


1 


Syntax  Notes:  In  tins  syntax,  the  'Name"  attribute  is  required  and  internal  lists  are 
forced  to  be  flat,  that'is,  attribute  values  cannot  be  lists  of  lists.  This  later  limitation  is  to 
avoid  the  temptation  to  hide  feature  lists  inside  other  feature  lists.  This  syntax  assumes 
that  the  lexical  analyzer  uses  any  amount  of  white^qce  as  separators  --  any  number  of 
spaces,  tabs,  line  feeds  or  carriage  returns.  Some  syntactic  distinctions  could  be 
simplified,  e.g.,  rates  and  dimensions,  but  these  extra  syntactic  categories  should 
simplify  semantic  interpretation. 

There  are  many  examples  of  this  syntax  in  later  sections  of  the  document. 
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8.  Built-In  Feature  List  Types 

Simple  Machined  Features 
Block 

Blind_Hole 

thru_H61e 

Hole_Chamfer 

Thread 

Slot 

Thru_Slot 

Rectangular_Thru_Slot 

Rotational-Groove 

Pocket 

Thni_Pocket 

Rectangular_Pocket  (?) 

Chamfer 

Channel 

Shoulder 

Squaring_Block  (?) 

Plane 

Angle  (?) 

Thru^Angle 

Convex_Angle 

Edge_Round 

Wedge 

Face 

Miscellaneous 

Part 

Surface 

Cutting_Operation 

Holding_C)peration 

Sensing_Operation 

Manager_Operation 

Message 


Defined 

1 

V 

s/ 


V 

V 


V 

V 

V 

V 

V 

V 
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9.  Feature  List  Definitions 

Each  built-in  feature  list  has  its  own  set  of  predefined  attributes.  Some  of  the 
predefined  values  must  have  a  particular  kind  of  value,  ^me  of  these  value  types  are 
consider^  obvious,  e.g.,  <Integer>  and  others  are  defined  above  as  part  of  the  feature 
list  syntax.  The  definitions  that  have  been  predefined  follow: 


(Name 

<Attrib>) 

(Type 

Thru_Hole) 

(Radius 

<Dimensions>) 

(Depth 

<Dimensions>) 

(P_Vector 

(<Dimensions>  <Dimensions>  <Dimensions>)) 

(D_Vector 

'(<Dimensions>  <Dimensions>  <Dimensipns>)) 

(Has_Parts 

<Valuc>) 

(Is_Part 

<Value>)) 

(Name 

<Attrib>) 

(Type 

Thru_Slot) 

(Width. 

<Dimensions>) 

(Depth 

<Dimensions>) 

(Length 

<Dimensions>) 

(P_Vector 

(<Dimensions>  <pimensions>  <Dimensions>)) 

(W_Vector 

(<DimensiDns>  <bimensions>  <Dimensions>)) 

(D_Vector 

(<Dimensions>  <Dimensions>  <Dimensions>)) 

(L_Vector 

(<Dimensions>  <Dimensions>  <Dimensions>)) 

(Has_Parts 

(<Value>) 

(Is^Part 

<Value>))) 

(Name 

<Attrib>) 

(Type 

Wedge) 

(Length 

<Dimensipns> 

(X_Angle 

<Dimensions> 

(Y_Angle 

<Dimensions> 

(Intersection 

<Dimensions>  ??  This  this  be  a  squared  value 

(P_Vector 

(<Dimensions>  <Dimensions>  <Dimensions>)) 

(W_Vector 

(<Dimensions>  <Dimensions>  <Dimensions>)) 

v(D_Vector 

(<Dimensions>  <Dimensions>  <Dimensions>)) 

(L^Vector 

(<pimensions>  <Dimensions>  <Dimensions>)) 

(Has_Parts 

<Value>) 

(Is_Part 

<Value>))) 
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(,  (Name 
(Type 
(Width 
(Height 
(Length 
(iP_Vector 
(W^Vector 
(D_yectpr 
(L_Vect6r 
(HasJParts 
(Is_Part 


<Attrib>) 

Block) 

<Dimensibns>) 

<Dimensions>) 

<Dimehsioris>) 

(<Dimensiphs>  <pimensions>  <Dimensi6ns>)) 
(<Dimensibns>  <Dimensibns>  <Dimensions>)) 
(<Dimensions>  <Dimensions>  <Dimensions?r)) 
(<Dimensions>  <E)imensibns?^^  <Dimehsiohs>)) 
<Value>) 

<Value>))) 


(  (Name 
(Type 
(Radius 
(Class 
(Has_Parts 
(Is_Part 


<Attrib>) 
Edge.Roimd) 
<Dimensions>) 
"Convex"  I  "Concave") 
<Value>) 

<Value>)) 


(  (Name 
(Type 
(Material 
(Units 
(Source 
(Surfaces 

(Presentation 

(Has_Parts 


<Attrib>) 

Fart) 

<Materials>) 

<Units> 

<Batch  Codes>) 

(<S^Type>  <S_Type>  <S_Type>  <S_Type>  <S_Type> 
<S_Type>) 

(<Side>  <Side>  <Side>)) 

<Value>)) 


(  (Name 
(Type 
(Class 
??Tolerance 
(Has_Parts 
(Is_Part 


<Attrib>) 

Sxirface) 

"Sawed"  r'Rolled"  !  "Machined") 

<Value>) 

<Value>)) 


(  (Name 
(Type 
(Units 
(NC_Name 
(NC_Frame 
(Safe_Zone 
(Tools 
(Speed 
(Feed 


<Attrib>) 

Cutting_Operatiqn) 

<Rate_Units>) 

<Attrib>) 

<Value>)  ;  We  might  want  to  make  this  a  separate  element 
<Value>) 

<Value>) 

<Rates>) 

<Rates>) ) 
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(Name 

<Attrib>) 

(Type 

Sensing_Gperation) 

(Concerns 

<Value>) 

(Warnings 

<yalue>) 

(Errors 

<Value>)) 

(Name 

<Attrib>) 

(Type 

Holdmg_Opcration) 

(Fixtures 

<Value>) 

(CutterJPaths 

<Value>) 

(Forces 

<Value>)) 

(Name 

<Attrib>) 

(Type 

Manager_Operation) 

(Models 

<Value>) 

(Actiye_Element 

<Attrib>) 

(Concerns 

<Value>)) 

(Name 

<Attrib>) 

(Type 

Message) 

(ReplyJTo 

<Attrib>) 

(From 

<System_Module>) 

(To 

(<System  Modules>)) 

(Priority 

<0..255>)' 

(Time 

<Time_Stamp>) 

(Subject 

<string>)) 
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10.  Special' Attributes  (Is„Pa£t  Mid  Has_Parts) 

There  are  two  very  special  attributes  called  ’TsJPart"  *'H^_PMts/'  T^ese  two 
elements  are  u^d  to  tie  the  structure  of  feature  lists  together.  The  Is_Part"relation  is 
used;  to  deteimihe  the  structiire  of  value  inherit^ce,J.e.,  what  are  the  default  values, 
While  the  H^JParts  relation,  is  used  toindicate  that  there  are  more  detmls  in  other  fea¬ 
ture  lists  and  it  may  be  necessary  to  consider  the  whole.  In  the  c^e  of  geometrical 
modelings  Has_Parts  can  be  used  to  trigger  modding  primitives  that  perform  additions 
and  subtractions  from  the  model. 


Figure  1:  Four  feature  lists  named:  A,B,C  andD 

Figure  1  is  a  graphical  illustration  of  the- connection  between  four  feature  lists.  In  this 
case,  we  recognize  that  the  Is_Part  and  HasJParts  relations  are  not  symmetric,  because 
"B"  is  not  included  as  part  of  "A's"  description.  This  hierarchy  of  feature  lists  could  be 
defined  as: 


(Define  ((Name  A) 

(Has_Parts  (CD))) 

((Name  B) 

(Is_Part  A)) 

((Name  C) 

(Is_Part  A)) 

((Name  D) 

(Is_Part  A))) 
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11.  Parsing  Feature  Lists 

(Dn  SyNS:^.d  oflier  UNIX  lx)xes,,LEX  YACC  can  te  i^d  to  define  a  parser  for  fea¬ 
ture  lists.  Tlie  output  of  the  parse  -wU,  in  these  cas^,  be  stored  in  C  shnctures. 

Bqilorere,  the  LKP  reader  will  be  used,  for  reading  the  feature  lists  into  LISP 
association  lists. 


12.  Message  Information 

Both  the  source  of  a  message  and  ihe  target  of  file  message  should  be  represented.  We 
can  decide  to  include  this  in  the  FEL  proper  or  we  can  let  the  mail  system  manage  this 
information  for  us.  Functionally,  the  result  will  be  the  same,  but  different  modules  will 
be  responsible,  depending  on  the  choice. 

We  may  also  want  to  add  other  features  to  messages,  such  as,  carbon  copies, 
forwarding  and  status-required  or  not. 


13.  Feature  List  Naming  Convention 

The  subsystem,  name  in  italics,  that  constructs  a  feature  list  must  mark  it  with  a  two 
letter  prefix,  whidi  corresponds  to  the  name  of  the  module.  In  this  way,  it  will  be  clear 
which  module  owns  every  feature  list.  This  becomes  important  when  we  wish  to 
maintain  consistency  between  values  in  our  distributed  environment. 


CT 

— 

CutTech  Database 

CX 

— 

putting  Eicpert 

HI 

— 

Human  interface 

HX 

Holding  E^qjert 

MX 

— 

Modeling  Ej^ert 

PM 

Plan  Manager 

PX 

— 

Planning  Expert 

SX 

~ 

Sensing  E^^rt 

UP 

Upstream  Processes,  e.g..  Designer,  Scheduler. 

We  may  want  to  break  this  category  down  further. 
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14.  Convention  for  Protecting  Distributed  Data 

The  feature  lists  are  meant  to  operate  in  a  ^tributed  envirpnnient,  which  can  cai^e 
many  database  management  , problems.  To  avoid  problems,  like  having  two  copies  of 
the  s^e  feature.  list  with  different  values,  we  will  enforce  a  restriction  that' makes  fea¬ 
ture  lists  "read  everywhere"  and  "write. and  delete  oftiy  at  tiie  home; subsystem."  Even 
this  restriction  may  be  too  we^,^uniess,  every  subsystem  remembers  who  has  copies.of 
that  subsystem's,  feature  lists.  This  means  it  .is  even  necess^  to  control  when  .the^ 
owner  of  the  feature  list  is  allowed  to  make  changes. 

For  example,  it  is  understood  that  a  negotiation  between  subprocesses  is  a  time  for 
making  changes.  But  once  values  have  been  jointly  settled,  then  that  feature  list  is 
effectively  closed.  To  imderstand  this  better,  a  negotiation  is  like  coming  to  terms  on  a 
contract  between  two  parties..  Once  an  agreemtot  has  been  devised,  ^hen  both  parties 
are  honor  bptmd  to  that  agreement  and  its  terms.  After  the  contract  has  been 
completed,  then  the  feature  list.is  obsolete  and  can  be  safely  removed. 

There  is  a.  further  need,  to  formalize  when  it  is  safe  to  modify  existing  feature  lists,  so 
that  consistency  can  be  guaranteed  without  giving  up  flexibility. 
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15.  Dialogues  and  Communication  States 


The  IM^  is  designed  so  that  any  two  subsystems  can  cany  blit  a  dialogue  at  any  time: 
These  dialogues  can  have  rhariy-puiposes,  whidK  c^  va^  fro.m  carrying  out  actual 
madiining  to  simply  ^ttlihg  on  a-.pl^.  V^ehever  two /systems  pairtidpate  in  such  a 
conversation,;they  miist  eadi  maintmh  the  dirrenbstate^^^  the  dialogue.  Li  fact,  these 
states  must  be  maintained  for  eoery  active  dialogue  diat  is  going  on  concurrently. 
Furthermore,  it  is  expected  that  both  p^tidpants  in  a  dialogue  maintain  their  own  state 
network. 


Sub^steml  Subsysteih-2 

Figure  2:  Two  subsystems  in  dialogue 


Figure  2  shows  two  subsystems  with  identical  state  machines,  which  represent  the  dia¬ 
logue  in  process.  The  first-subsystem  which  began  in  the  first  state,  issued  a  message 
to  the  second  subsystem  and  then  advanced  to  the  second  state.  The  second  subsystem 

remains  in  the  first  state  until  it-.receives  the  incoming  message  M  after  which  it  also 

advances  to  the  second  state.  The  dialogue  between  the  two  subsystems  in  not  consid¬ 
ered  complete  until  both  state  machines  return  to  the  initial  state.  Practically  speaking, 
the  state  machines  are  automatically  created  and  purged  as  individual  dialogues  are 
started  and  then  completed. 

Most  communications  can  be  handled  with  a  simple  three  state  machine.  Figure  3 
shows  a  three  state  machiiie  for  one  participant  that  starts  in  S  and  usually  proceeds 
through  two  intermediate  states  in  the  process  of  completing  a  request.  However,  on 
occasion  it  is  possible  to  detennine  that  the  request  can  be  immediately  satisfied  or  that 
it  cannot  be  satisfied  at  all.  In  this  case,  the  dialogue  can  be  brought  to  an  immediate 
end. 
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Figure  3:  Simple  Three  state  communications 


In  this  network,  there  are  two  kinds  of  arcs:  bold  arcs  indicate  that  the  message  is 
received  and  plain  arcs  represent  that  the  message  is  sent  to  the  other  participant. 
Therefore,  if  a  subsystem  is  the  origin  of  a  dialogue  then  it  is  allowed  to  initiate  the  bolci 
arcs,  while  if  a  subsystem  is  the  target  of  dialogue  then  that  subsystem  is  allow  to  ini¬ 
tiate  the  plain  arcs.  On  the  other  hand,  the  origin  of  a  dialogue  is  expecting  to  receive 
messages  on  plain  arcs,  while  the  target  of  a  dialogue,  is  expecting  to  receive  messages 
on  bold  arcs.  Figure  3  also  raises  a  potential  problem.  Once  a  subsystem  is  in  the 
active  state,  "making"  in  Figure  3,  it  may  have  to  be  forced  out  of  it  by  the  verb 
"Stop_Making,"  otherwise  there  -would  be  no  way  to  cancel  an  action  once  it  had 
started. 

These  state  machines  are  quite  powerful,  but  cannot  handle  all  of  the  complexities  that 
we  wish  to  capture  in  a  negotiation  process.  However,  Figure  4  shows  that  with  the 
addition  of  one  state  it  is  possible  to  add  a  negotiation  Icxap,  between  state  3  and  state  4, 
and  still  be  able  to  keep  track  of  which  subsystem  has  the  proverbial  ball. 


Figure  4:  Complex  Four  state  communications  or  negotiation 
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First,  the  origin  of  a  negotiation  decides  that  it  requires  information.on  several  features. 
It  then  sends  out  a  possibly  empty  feature  list  to  be  filled  in  by  the  source  of  the  mes¬ 
sage.  That  is  the  origin  requests  an  "offer"  for  possible  values,  When  the  source  of  the 
message  calculates  &e  appropriate  values  to  return  it  is  "offering'  a  response,  one  of 
possibly  many.  The  source  of  the  original  request  can  then  make  a  coimter  offer  or  sim¬ 
ply  state  that  the  original  offer  has  been  "accepted." 

Another  strategy,  see  Figure  5,  for  a  simple-kind  of  negotiation  can  use  another  sub- 
‘.system  just  to  vdidate  the  terms,  of  an  agreement.  In  this  case,  an  "accept"  command  is 
/Sent  to  a  second  system  and  a  response  comes  back  indicating  whether  or  not  the  terms 
have  been  accepted. 
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16.  Modeling  Stock  Example 

This  long.example.starts  with  one.subsystem  called  a  planner  sending  part  information 
onto  Other  systems  that  will  al^  need,  the  iitformatioh.  Since  this  information  was  not 
requested,  the  "define"  verb  is  used.  The  idea  is  that  each  subsystem  will  process  this 
feature  list  by  building  up  a  three  dimensional  model  using  tools  in  MFGMAP. 

Note  that  in  this  case  the  feature  list  was  originally  defined  by'^,  upstream  process  and 
passed  dov/n  to  the  planner.  The  planner  at  this  point  is  not  given  the  authority  to 
delete  this  feature  list  without  a  request  from  the  upstream  processes. 


Planner: 


(Define 


) 


((Name 

UP_Stock_Geometry) 

(Type 

Block) 

(Width 

2.1  inches) 

(Height 

2.1) 

(Length 

2.1) 

.(P_Vector 

(0.0  0.0  0:0)) 

(D_Vector 

(6.0  2.1  0.0)) 

(W_Vector 

(0.0  0.02.1)) 

(L_Vector 

(2.1  0.6  0.0)) 

(Is_Part 

UP_Stock_Part)) 

((Name 

UP_Stock^Part) 

(Type 

Part) 

(Units 

inches) 

(Material 

Aliuhinum) 

(Source 

<Batch  #>) 

(Surfaces 

(Rolled  Sawed  Rolled  Rolled  Sawed  Rolled))) 

(Presentation 

(123)) 

(Has_Parts 

UP_Stock_Geometry)) 

((Name 

PL_Init_Stock) 

(Type 

Message) 

(From 

Planner) 

(To 

(Manager  Cutting  Holding  Sensing))) 

We  can  see  from  this  first  message  that  there  are  several  desirable  system  features. 
First,  optional  imd  required  arguments  must  be  handled  ^acefully,  and  secondly  that 
default  values  can  be  used  at  any  time.  In  this  case,  "inches"  are  specified  by  the 
"UP_Stock_Part"  feature  list  and  the  units  are  essentially  inherited  from  this.  Finally,  it 
shoiUd  be  noted  that  the  definition  of  the  stock  material  was  defined  in  an  upstream 
process,  i.e.,  was  input  to  the  IMW. 
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Now  the  answers  start  coming  back  from  the  different  subsystems.  In  cases  of  simple 
data  transfer,  there  is  not  a  need  to  represent  the  active  state  of  verbs.  Aprocess  has  the 
option  of  sending  a  completed  message,  i.e.,  past  tense,  immediately.  Howeyer,  some 
confinhatibn  must  be  serit  back  to  the<soufce  of  a  message  for  every  featuferiist  in  the 
message,  except  elements  of  type  "message."  Also  the  messages  can  be  received  in  any 
order. 

Cutting:  (Defined  UP_Stock_Geometry 

UP_Sto^_Part 
((Reply_To  PL_^Init_Stock) 

(Type  Message) 

(From  Cutting 

(To  Planner))) 


Manager:  (Defined 


UP_Stock_Geometry 
UP_Stock_Part 
((Reply_to  PL_Init_Stock) 
(T3rpe  Message) 

(From  Manager) 

(To  Planner))) 


Sensing:  (Defined  UP_Stock_Geometry 

UP_Stock_Part 
((Reply_To  PL_Init_Stock) 

(Type  Message) 

(From  Sensing) 

(To  Planner))) 

Holding:  (Defined  UP_Stock_Geometry 

UP_Stock_Part 
((Reply_To  PL_Init_Stock) 

(Type  Message) 

(From  Holding) 

(To  Planner))) 


Naming  every  mail  message  can  be  annoying,  however,  there  is  a  strong  need  for 
accountability.  Therefore,  it  is  a  good  convention  to  name  original  mail  messages. 
Responses  can  then  invoke'the  original  name  (e.g.,  with  Reply_To)  and  thus  it  avoids 
unnecessary  new  names.  At  the  same  time,  this  convention  simplifies  the  naming  and 
management  of  reply  mail. 

A  future  refinement  will  be  to  find  a  more  concise  way  to  fully  represent  all  of  the 
message  oriented  information. 
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17.  Modeling  The  Part 


In  this  example,  we  ^e  going  to  define  a.  part  that  is^essentially  a  squ^ed  block  with 
one  cut  hole,,  whidi  will  be  cut  from  the  previoasly  defined  stock  part.  Note  &at  in 
these  definitions  the  geometry  Is_Part  part  and  is  not  an  operation.  Again>  this  feature 
list  will  be  used-  to  drive  the  primitive  functions  of  MFGMAP  in  order  to  m.ake'a  full 
three  dimensional  model. 


Planning:^  (Define  ((Name 

(Type 

(Width 

(Height 

(Length 

(P_Vector 

(D_yector 

(W_Vector 

(L_Vector 

(Has_Parts 

(Is_Part 

((Name 

(Type 

(Radius 

(Depth 

(P_Ve(:tor 

(D_Vector 

(Is_Part 

((Name 

(Type 

(From 

(To 


UPJSeomeify) 

Block) 

2.6) 

2.0) 

2.0) 

(0:0  0.0  0.0)) 

(0.0  2.0  0.0)) 

(0.0  0.02.0)) 

(2.0  0.0  0.0)) 

UP_Center_Hole) 

(LrP_Stock_Part  UP„Stock_Geometry))) 

lJP_Center_Hole) 

Thru_HoleF 
.25)  . 

2.0) 

(1.02.01.0)) 

(1.0  0.01.0)) 

UP_Surface)) 

PL_Part) 

Message) 

Planner) 

(Manager  Cutting  Holding  Sensing))) 


Manager:  (Defined  UP_Geometry'UP_Center_Hole  UP_Part ... ) 

Cutting:  (Defined  UP_Geometry  UP_Center_Hole  UP_Part ... ) 

Sensing:  (Defined  UP_Geometry  UP_Center_Hole  UP_Part ... ) 

Holding:  (Defined  UP_Geometiy  UP_Center_Hole  UP_Part ... ) 
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18.  Negotiation  Example 

In  this  example,  the  planner  sends  out  messages  to  every  subsystem  at  the  same  time. 
This  will  cause  the  subsystems  to  develop  plans  fliat  are  independent  of  eaA  other  and 
will  give  the  planner  a  ch^ce  to  study  die  conflicts.  An  optional  scen^b  would  be  to 
send  each  of  the  subsystems  a  message  in  sequence,  while  imposing  successively 
stronger  constraints  on  each  system  in  the  list  Whiln,  this  organization  may  seem 
simpler  than  the  parallel,  strategy,  it  will  not  always  converge  on  the  best  solution.  For 
example,  a  solution  proposed  first  by  .the  cutting  subsystem  may  unnecessarily  over 
constrain  the  holding  subsystem,  which  could  result  in  a  second  rate  solution  for 
holding  even  though  the  cutting  system  was  ambivalent. 


Planner: 

(Offer  ((Name 
(Type 
(Is_Part 

PL  Center  Hole  Op 

Thru_Hole) 

(Operation  UP_Center_Hole)) 

((Name 

(Type 

(From 

(To 

) 

PL_Offerl) 

Message) 

Planner) 

(Manager  Cutting  Holding  Sensing)) 

Cutting: 

(Offering  ((Name . 
(Type 
(Tools 
(NC_Name 
(Speed 
(Feed 

CX_Center_Hole_Op 

Operation) 

(Drill2)) 

Peck  Hole) 

20) 

20)) 

((Reply_To 

(From 

(To 

PL_Offerl) 

Cutting) 

Planner))) 

Holding: 

(Offering  ((Name 
(Type 
(Fbeture 
(Top  Face 
((Replyjro 
(From 
(To 

CX_Center_Hole_Op 

Operation) 

(Fixed) 

4) 

PL_Offerl) 

Holding) 

(Planner  Manager))) 
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At  this  point  in  the  processing,  the  sensing  system  could  respond  with  potential 
problems.  For  example,  without  yet  knowing  about  the  cutter,  it  is  appropriate  to 
worry  about  tool  wear  and  tool  breakage.  It  is  also  appropriate  to  worry  about 
potential  clogging  of  the  drill  which  is  often  a  problem  when  cutting  aluminum. 
Finally,  the  surface  finish  around  the  hole  might  have  burrs  that  have  been  "pulled  out" 
from  the  hole.  Hiese  problems  can  be  addressed  in  a  number  of  ways,  including  using 
a  different  drill  and  adding  more  steps  to  die  process,  e.g.,  a  small  hole  chamfer.  Of 
course,  as  concerns,  they  can  be  ignored. 


Sensing: 

(Offering  ((Name 

CX_Center_Hole_Op 

(Type 

Operation) 

(Concerns 

(Tool_Breakage 

Surface_Burrs 

Chip_Clogs)) 

((Reply_To 

PL_Offerl) 

(From 

Sensing) 

(To 

(Planner  Manager))) 

Manager: 

(Offering  .((Name 

CX_Center_Hole_Op 

(Type 

Operation) 

((Reply_To 

(From 

(To 


PL.Offerl) 

Manager) 

Planner))) 
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19.  Setup  Example 


Planner: 

(Make 

UP_Part 

((Name 

(Type 

(From 

(To 

PL_Workpackage) 

Message) 

Plartner) 

Manager))) 

Manager: 

(Making 

UP_Part 

((ReplyJTo 

(Type 

(From 

(To 

PL^Workpackage) 

Message) 

Manager) 

Planner))) 

Manager: 

(Make 

HX_Setupl 

((Name 

(Type 

(From 

(To 

PM_Setupl) 

Message) 

Manager) 

(Holding  Sensing))) 

Holding: 

(Making  HX_Setupl 
((ReplyJTo 
(Type 
(From  • 

(To 

PM_Setupl) 

Message) 

Holding) 

Manager))) 

Sensing: 

(Get 

HX_Setupl 

((Reply_To 

(Type 

(From 

(To 

SX_Get_Setup:) 

Message) 

Sensing) 

Holding))) 

Holding: 

(Got 

((Name 

...) 

HX_Setupl) 

((Type 

(Reply_To 

(From 

(To 

Message) 

SX_Get_Setupl) 

Holding) 

Sensing)) 

Sensing: 

(Monitoring  HX_Setupl 
((Type 
(ReplyJTo 
(From 
(To 

Message) 

PM_Setupl) 

Sensing) 

Manager))) 

Holding: 

(Made 

HX_Setupl 
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Sensing: 


((Type 

Message) 

(Reply_To 

PM_Setupl) 

(From 

Holding) 

(To 

Manager))) 

(Monitored  HX_Setupl 

((Type 

Message) 

(Reply_To 

PM_Setupl) 

ffrom 

Sensing) 

(To 

Manager))) 

20.  Machining  Example:  Part  Completed 


Manager: 

(Made  UP_Part 

( (Reply_To 

PL_Workpackage) 

(Type 

Message) 

, 

(From 

Manager) 

(To 

Planner))) 

After  a  part  has  been  accepted  by  the  upstream  process,  it  then  issues  authorization  to 
delete  the  stock  and  part  descriptions,  which  is  then  passed  on  to  the  various 
subsystems. 

Upstream:  (Delete  UP_Stock_Part 

UP_Stock_Geometry 

UP_Finished_Part 

lJP_Finished_Geometry 

UP_Center_Hole 

((Name  UP_Completed) 

(Type  Message) 

(To  Planner) 

(From  Upstream))) 

Planner:  (Deleted  UP_Stock_Part 

UP_Stock_Geometry 

UP_Finished_Part 

UP_Finished_Geometry 

UP_Center_Hole 

( (Reply_To:  UP_Completed) 

(Type  Message) 

(To  Upstream) 

(From  Planner))) 
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This  example  suggests  "wildcards"  in  name  could  be  very  useful,  such  as  UP_*,  which 
would  mean  that  dl  feature  lists  that  start  with  "UP_"  should  be  deleted. 
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FEL  Interface  to  the  Planning  Expert 


This  section  assumes  that  the  reader  has  some  familiarity  with:  FEL  syntax,  the 
Iv^CHINISTV  and  the  Modeler^. 

The  Planning  Expert  (PX)  is  based  pn  fhe  MACHINIST,  a  program  designed  and 
written  by  Caroline  Hayes.  The  MACHINIST  is  a  process  planner  that  produces 
manufacturing  plans  for  machined  parts.  PX  simply  the  integration  of  the  MACHINIST 
and  the  Lisp-b^ed  Generic  Expert.  This  integration  allows  input  to,  and  output  from, 
the  MACHINIST  to  be  via  FEL  sentences. 


1.  Input  to  PX 

PX's  function  is  to  produce  a  manufacturing  plan  for  a  specified  part.  In  order  to 
accomplish  this  task,  certain  information  is  required  by  PX.  The  Process  Planner  needs  a 
desCTiption  of  the  stock  envelope,  the  part  envelope,  and  the  features  that  comprise  the 
part.  The  Modeler  is  the  expert  that  will  be  queried  for  that  information. 


1.1. '  Creating  the  Model 

In  order  for  PX  to  plan  for  the  machining  of  a  part,  the  Modeler  must  have  a  model 
of  the  part  and  stock  objects.  The  model  of  the  part  object  will  include  a  specification 
for  ea(^  of  the  part's  feature.  The  ADD  sentence  that  follows  is  input  to  MX  that  would 
CTeate  a  part  object  named  boss,  and  a  stock  object?  named  S0235.  The  part  and  stock 
models  created  by  this  sentence  will  be  referred  to  in  subsequent  examples. 


{  (name 

G0927) 

(type 

message) 

(to 

mx)  ) 

(  (type 

application) 

(name 

planner)  ) 

( (name 

imw) 

(type 

environment) 

(application 

planner)  ) 

(  (name 

S0235) 

(type 

object) 

(material 

aluminum) 

(p_vector 

(0.0  0.0  p 

1.  The  term  Process  Planner  will  be  used  as  a  synonym  for  MACHINIST . 

2.  The  tenns  MX  and  Modeler  will  be  used  interchangeably  to  refer  to  the  Modeling  Expert. 

3.  For  a  detailed  explanation  of  the  attributes  used  in  the  ADD  sentence/ see  the  section  in  this 
document  entitled,  FEL  Syntax  for  Communicating  vrith  a  Geometric  Modeler. 
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(w^vector 

(3.5  0.0 

0.0)) 

(l_vector 

(0.0  2.5 

0.0)) 

(d_vecto,r 

(0.0  0.0 

1.5)),  ) 

(name 

boss) 

(type 

object) 

(material 

aluminum) 

(p_vector 

(0.0  0.0 

0.0)) 

(w_vector 

(3.0  0.0 

0 . 0) ) 

^_vector 

(0.0  2.0 

0.0)) 

(d_vector 

(0.0  0.0 

1.0))  ) 

(name 

thrul) 

(type 

thru_hole) 

(object 

boss) 

(p_vector 

(1.5  1.0 

1.0)) 

(d_Yector 

(0.0  0.0 

-1.0)) 

(radius 

0.3)  )) 

Figure  1  is  a  graphical  representation  of  boss,  the  part  object  added  to  the 
Modeler. 


Figure  1.  The  part  to  be  machined. 


1.2.  Queiymg  the  Modeler 

MX  may  contain  models  for  many  objects.  So,  if  PX  is  to  construct  a  plan,  it  needs 
certain  information  in  order  to  be  able  to  locate  the  desired  part  and  stock  objects  in  the 
Modeler's  hierarchy.  That  is,  the  requester  of  the  manufacturing  plan  must  provide  the 
name  of  the  application,  the  environment,  the  part,  and  the  stock.  Hence,  the  initial 
function  of  PX*^  expects  an  FEL  sentence  of  the  following  form^: 

(plan  (  (name  <name>) 

(type  planning_op) 

(application  <application-name>) 

(environment  <environmsTit-name>) 


4.  The  initial  function  is  the  function  executed  by  the  generic  expert  component  of  an  expert  when  a 
sentence  arrives  that  initiates  a  new  dialogue. 

5.  Typically,  example  FEL  sentences  will  not  indude  the  feature  list  of  type  message. 
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(part  <part-name>) 

(stock  <stock-name>)  ) ) 

Currently,  PX's  initial  function  is  only  capable  of  performing  meaningful  actions  for  a 
plan  sentence  (that.is,  a  sentence  with  the  verb  plan).  The  sentence  should  contain  one 
feature  list  of  type  planning_op.^  This  feature  list  contains  information  that  will  allow 
PX  to  query  MX.  The  values  of  the  attributes  application'^  and  environment  specify 
the  location  of  the  objects  in  the  Modeler's  hierarchy.  The  values  of  the  attributes  part 
and  stock  are  the  names  of  the  objects  about  which  the  process  planner  needs  feature 
information. 

Once  PX  has  extracted  the  names  of- the  part  and  stock  objects  from  the  plan 
sentence,  the  next  step  is  to  query  the  Modeler-for  the  features  that  are  associated  v^dth 
both  of  these  objects.  Therefore  two  dialogues  are  initiated  with  MX.  One  of  the 
dialogues  requests  the  features  of  the  part  and,  the  other,  requests  the  features  of  the 
stock®. 

Following  are  two  sentences  (a  request  and  a  reply)  that  represent  a  sample 
dialogue  between  PX  and  MX.  The  purpose  of  the  exchange  is  for  PX  to  obtain  the  names 
of  the  features  associated  with  the  part.  The  part  is  an  object  named  boss  that  resides 
in  the  application,  planner,  and  the  environment,  imw. 


(get 


(got 


(  (name 

px_l). 

(type 

message) 

(to 

•  mx) 

(from 

px)  ) 

( (name 

boss 

(type 

object) 

(application 

planner) 

Environment 

imw)  ) ) 

(  (name 

px_l) 

(type 

message) 

(to 

px) 

(from 

mx)  ) 

(  (name 

boss 

(type 

object) 

(application 

planner) 

(environment 

imw) 

(material 

aluminum) 

6.  PX  is  not  smart  enough  to  be  able  to  plan  more  than  one  part  per  dialogue. 

7.  The  attribute  .'application  is  optional.  If  it  is  not  provided,  then  the  symbol  :  planner  is  used  as 
the  value  for  this  attribute. 

8.  One's  initial  thought  might  be  that  the  stock  has  no  features;  however,  that  is  not  the  case.  Associated 
with  every  object  is  a  rectangular  bounding  box.  This  is  a  feature  of  the  object  and  is  known  as  the 
envelope  of  the  object.  Knowledge  about  the  part  and  stock  envelopes  is  very  important  to  the 
MACHINIST. 
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(feature  (envelope  hole) )  ) ) 

Once  both  of  the  dialogues  with  MX  have  terminated,  the  returned  FEL  sentences 
are  dissected.  At  this  point,  each  sentence  contains  two  attribute/value  pairs  that  are  of 
interest  to  PX.  The  attributes  of  importance  are  material  and  feature. 

The  vdue  of  the  attribute  material  specifies-the  material  composition  of  the 
object^.  This  information  is  converted  into  a  data  structure  that  will  be  processed  by  the 
MACHlNiST^®.  In  the  preceding  example,  the  part  will  machined  out  of  aluminum. 

Associated  with  each  object  is  a  set  of  features.  For  each  of  these  features,  the 
Modeler  contains  detailed  ihformation.  The  process  of  acquiring  that  information  from 
MX  commences  once  the  names  of  all  of  the  features  are  known  to  PX.  These  names  are 
the  elements  of  the  list  that  is  the  value  of  the  attribute  feature.  These  feature  names 
will  generate  the  next  round  of  dialogues  with  the  Modeler.  The  above  example,  would 
involve  two  distinct  dialogues.  One  for  each  of  the  features  named;  that  is,  envelope 
and  hole. 

For  each  feature  associated  with  an  object,  a  get  request  will  be  sent  to  the 
Modeler  (each  of  the  requests  initiating  a  new  dialogue).  The  responses  to  these  queries 
will  contain  information  needed  by  the  MACHINIST.  As  an  example,  if  PX  wanted  to 
obtain  modeling  information  about  a  feature  named  hole,  associated  with  the  object, 
boss,  in  the  application,  planner,  and  the  environment,  imw;  then  the  following  FEL 
sentence  would  be  sent  to  MX. 


9.  It  should  come  as  no  surprise  that  the  part  and  stock  objects  should  have  the  same  value  for  the 
attribute  tmaterlal. 

10.  The  MACHINIST  is  an  expert  ^stem  that  utilizes  the  rule-based  progranuning  language,  OPs5.  Asa 
consequence,  the  data  structures  processed  by  the  MACHINIST  are  Working  Memory  Elements. 
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(environment 

(6pens_on 

(distance 

(radius 

(depth 


imw) 

(mx_7  mx_9) ) 

(  (mx_ll  1.5)  (mx  8  0.5)  )) 
0.3) 

2.0)  )). 


Actually,  the  Modeler  returns  more  information  than  is  shown;  but  only  a  subset 
of  the  attribute/ value  pairs  returned  in  the  feature  list  of  type.thru_hole  are  needed 
by  PX.  MX  is  the  modeling  expert  to  all  experts.  It  is  the  duty  of  the  expert  requesting 
information  to  parse  the  FEL  sentence  and  extract  the  attribute/ value  pairs  that.make 
sense  to  it. 


Initially,  PX  only  knows  the  name  of  the  feature;  in  this  case  hole.  Once  the 
preceding  got  sentence  is  received,  PX  can  determine  the  feature  type  of  hole.  First, 
the  feature  list  that  contains  the  attribute/value  pair,  (name  hole),  islocated^^  From 
that  feature  list,  the  value  of  the  attribute  type  will  provide  the  type  of  feature.  In  the 
current  example,  the  value,thru_hole,  denotes  that  the  feature  is  a  through  hole. 

When  PX  knows  the  type  of  feature,  then  it  knows  which  elements  (that  is, 
attribute /value  pairs)  to  extract  from  the  feature  list.  The  attribute/ value  pairs  arrive  in 
a  form  that  the  MACHINIST  is  not  capable  of  processing.  Therefore,  steps  are  taken  to 
transform  the  "raw"'  information  into  the  data  structures  used  by  ^e  MACHINIST.  Since 
the  Process  Planner  is  implemented  in  OPS5,  these  data  structures  are  Working  Memory 
Elements. 


For  example,  the  attribute/ value  pair: 

(distance  ( (mx_ll  1.5)  (mx_8  0.5))) 
is  converted  into  the  following  Working  Memory  Elements: 


(center  dist 


''of  hole 

"'from  <name  used  by  machinist  for  mx_ll> 
''is  1.5 

''status  filled) 


(center  dist 


''of  hole 

''from  <name  used  by  machinist  for  mx_8> 
''is  0.5 

''status  filled). 


11.  It  is  possible,  though  not  likely,  for  the  dialogue  to  have  the  same  name  as  the  feature.  In  other 
words,  the  feature  list  of  type  rmessage  and  the  feature  list  of  type  ;  thru_hole  have  the  same 
value  for  the  attribute  :  name.  PX  takes  this  into  account,  by  ignoring  the  feature  list  of  type 
rmessage. 
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1.3.  Feature  Lists  for  Features:  the  AttributeA^alue  Pairs  of  Interest 

From  the  perspective  of  the  Process  Planner,  the  Modeler  can  currently  provide 
information  for  the  features^^:  blind_hole,  envelope,  thru_  ^gle,  thru_hole,  and 
thru_slot.  The  following  sections  cover  those  five  features.  Specifically,  the 
attribute/ value  pairs  of  interest  to  PX  ^e  listed  and  explained  for  the  feature  in 
question. 


1.3.1.  Blind_Hole 

In  a  feature  list  of  type  blind_hole,  the  attribute/value  pairs  of  interest  to  PX 
are  those  with  the  attributes: 


depth 


distance 


©pension 


radius 


The  value  of  this  attribute  is  a  real  number  which  gives  the 
depth  of  the  hole. 

The  value  of  this  attribute  specifies  the  center  of  the  hole.  The 
value  is  of  the  form: 

((side,  distancej )  (side^  distance^)). 

i  X  J  J 

This  gives  the  hole's  center  by  providing  the  distance  of  the 
center  of  the  hole  from  two  orthogonal  sides  of  the  envelope  of 
the  part  object. 

This  attribute's  value  is  a  list  of  one  element,  a  face  name  from 
the  set  of  face  names  assigned  to  the  part  envelope  by  MX.  The 
face  name  denotes  the  face  upon  which  the  hole  opens. 

The  value  of  this  attribute  is  a  real  number  that  gives  the  radius 
of  the  blind  hole. 


1.3.2.  Envelope 

The  envelope  describes  a  rectangular  bounding  box  around  an  object.  Remember, 
the  MACHINIST  expects  two  objects,  the  part  and  the  stock.  Associated  with  each  of 
these  objects  is  an  envelope  feature. 

The  Process  Planner  and  the  Modeler  use  different  naming  schemes  for  surface 
finishes  and  face  names.  But  experts  who  wish  to  converse  with  PX,  should  not  be 
concerned  with  the  naming  conventions  used  by  MACHINIST.  Hence,  mapping 
functions  are  employed  by  PX  to  translate  between  the  differing,  naming  schemes. 

12.  The  Modeler  can  model  more  than  these  five  features.  However,  the  other  feahires  are  currently 
described  in  terms  of  vectors.  Since  the  Process  Planner  is  feature  based,  information  concerning 
vectors  is  of  limited  utility. 
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For  the  surface  finishes,  the  correspondence  between  the  two  schemes  is  known  a 
priori.  Therefore,  that  mapping  function  is  aeated  at  system  start-up.  However,  that  is 
not  the  case  for  face  names.  The  names  attached  by  MX  to  the  face  of  an  envelope  are 
dynamic;  that  is,  they  ^e  aeated  when  the  model  is  added  to  the  Modeler.  Hence,  PX 
uses  the  information  provided  in  the  envelope  feature  list  to  set  up  a  mapping  function 
between  the  names  used  by  the  Modeler  and  the  names  employed  by  MACHINIST.  The 
result  is  that  when  experts  converse  with  PX,  they  do  not  have  to  be  concerned  with 
how  the  Process  Planner  represents  face  names  or  surface  finishes.  A  single 
representation  can  be  used;  that  of  the  Modeler. 

In  a  feature  list  of  type  envelope,  the  attribute/value  pairs  of  interest  to  PX  are 
those  with  the  attributes: 

distance  The  value  of  this  attribute  specifies  the  dimensions  of  the 

envelope.  The  value  is  of  the  form: 

(  (side^^  side2  distanceQ^) 

(side^  side^  distance2) 

(sideg  sideg  di.stance3)  ). 

Each  element  of  the  list  specifies  the  distance  between  two 
parallel  faces  of  the  envelope.  Let  X  be  such  an  element.  The 
first  two  elements  of  X  are  face  names  from  the  set  of  face  names 
assigned  to  the  part  envelope  by  MX,  with  the  added  constraint 
that  the  faces  be  parallel  to  one  another.  The  third  element,  a 
real  number,  is  the  distance  between  these  two  faces.  So,  if  X  is 
equal  to: 

(side^  side^  distance2) 

then  side3  is  parallel  to  side^  and  distarice2  is  the 
distance  separating  these  two  faces. 

finish  This  attribute's  value  is  a  list  of  the  form: 

( (side^  finish^^)  ...  (sideg  finishg)). 

sidejL  (where  i  =  1  to  6)  is  a  face  name  from  the  set  of  face 
names  assigned  to  the  part  envelope  by  MX,  and  finishj^  is  the 
surface  finish  of  that  face,  f  inishj^  may  be  assigned  one  of  the 
values:  none^^  machined,  rolled,  or  saw_cut. 


13.  If  the  Modeler  has  assigned  a  value  of  none  to  a  face,  then  PX  assumes  the  face  is  saw  cut.  The  value 
of  saw__cut  is  chosen,  since  that  presents  a  worst  case  scenario. 
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normal  The  value  of  this  attribute  is  aJist  of  the  form: 

( (side-j-  normal^)  ...  (sideg  normalg)). 

side  (where  i  =  1  to  6)  is  a  face  name  from  the  set  of  face 
n^es  assigned  to  the  part  envelope  by  MX.  normal is  the 
unit  normal  vector  for  that  face. 


1.3.3.  Thru_Angle 

In  a  feature  list  of  tfpa  thru_angle,  the  attribute/value  pairs  of  interest  to  PX 
are  those  with  the  attributes: 

angle  This  attribute's  value  is  a  list  of  two  elements.  The  first  element 

is  a  face  name  from  the  set  of  face  names  assigned  to  the  part 
envelope  by  MX.  The  second  element  is  a  real  number  between 
0  and  90,  exclusive.  The  second  element  is  the  degree  of  the 
angle  formed  by  the  new  face  created  by  the  feature  and  the  face 
given  by  the  first  element.  In  Figure  2,  for  example,  the  value  of 

the  attribute,  angle,  could  be  either  (B  8),  or  (E  (]));  where  (j> 

=  (90-0),  . 

distance  The  value  of  this  attribute  gives  the  distance  from  one  of  the 
faces  not  affected  by  the  thjru  angle  to  ,a  vertex  of  an  angle 
formed  by  the  feature.  The  value  is  of  the  form: 

{ (sidejL  distance^^) ) . 

side^  is  the  name  of  a  face  not  affected  by  the  thru  angle. 

Consequently,  it  will  not  be  an  element  of  the  value  of  the 
attribute,  opens_on.  distance  is  the  distance  along  an 

orthogonal  face  to  a  vertex  of  the  angle  formed  by  the  thru 
angle.  For  example,  in  Hgure  2,  this  attribute's  value  could  be 

either  ( (D  5) )  or  ( (F  ©) ) , 

opens__on  This  attribute's  value  is  a  list  of  four  elements,  all  are  face  names 
frorrvthe  set  of  face  names  assigned  to  the  part  envelope  by  MX. 
The  four  faces  are  those  that  the  thru  angle  feature  will  open  out 
upon.  That  is,  if  we  envision  the  tool  mal^g  this  feature,  these 
faces  will  have  the  tool  pass  through  them.  In  Figure  2,  the  thru 
angle  opens  out  upon  the  faces:  A,  B,  C,  and  E. 
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Figure  2.  A  block  with  a  thru  angle  feature. 


1.3.4.  Thru_Hole 

In  a  feature  list  of  type  thru_hole,  the  attributes  whose  values  are  meaningful  to 
PX  are: 

depth  The  value  of  this  attribute  is  a  real  number  which  gives  the 

depth  of  the  hole. 

disteuice  The  value  of  this  attribute  specifies  the  center  of  the  hole.  The 
value  is  of  the  form: 

( (sidej^  distancsj^)  (sidej  distancej)). 

This  gives  the  hole's  center  by  providing  the  distance  of  the 
center  of  the  hole  from  two  orthogonal  sides  of  the  envelope  of 
the  part  object. 

opens__on  This  attribute's  value  is  a  list  of  two  elements,  both  are  face 

names  from  the  set  of  face  names  assigned  to  the  part  envelope 
by  MX.  These  two  faces  are  the  opposite  sides  of  tihe  envelope 
upon  which  the  hole  opens. 

radius  The  value  of  this  at'jibute  is  a  real  number  that  gives  the  radius 

of  the  thru  hole. 
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1.3.5.  Thru_Slot 

In  a  feature  list  of  type  thru_slot,  the  attribute/value  pairs  of  interest  to  PX  are 
those  with  the  attributes: 

depth  This  attribute's  value  is  a  real  nuntber  that  gives  the  depth  of 

the  slot  from  the  part  envelope.  In  Figure  3,  this  would  be  (j). 

distance  The  value  of  this  attribute  gives  the  distance  from  a  face,  to  the 

closest  edge  of  the  thru  slot  The  value  is  of  the  form: 

( (side^  distancsj^) ). 

side^  is  the  name  of  a  face  that  meets  two  conditions:  (i)  it  is 

not  affected  by  the  thru  angle,  and  (ii)  the  face  is  not  parallel  to 
the  bottom  of  the  slot  distance^  is  the  distance  from  side 

to  the  closet  edge  of  the  thru  slot.  For  Figure  3,  an  example  of  a 
value  for  distance  is:  { (A  a) ) 


opens__on  This  attribute's  value  is  a  list  of  three  elements,  all  are  face 

names  from  the  set  of  face  names  assigned  to  the  part  envelope 
by  MX.  The  three  faces  are  those  that  the  thru  slot  feature  will 
open  out  on.  That  is,  if  we  envision  the  tool  making  the  feature, 
these  faces  will  have  the  tool  pass  through  them. 

width  This  attribute's  value  is  a  real  number  that  gives  the  width  of 

the  slot  This  is  the  value,  P,  in  Figure  3. 


Figure  3.  A  block  with  a  thru  slot  feature. 
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2.  Output  from  PX 

The  MACHINIST  is  run  once  the  information  from  the  Modeler,  that  desaibes  the 
part  and  stock  objects,  has  been  received  and  transformed  into  OPS5  Working  Memory 
Elements.  Originally,  the  result  of  a  run  of  die  MACHINIST  was  simply  displayed  to  the 
terminal.  This  is  of  little  use  to  an  expert  that  requests  a  machining  process-plan. 

Hence,  part  of  the  function  of  PX  is  to  gather  the  plan  together  and  construct  an  PEL 
sentence  that  embodies  the  plan.  This  sentence  i^l  be  returned  as  the  response  to  the 
original  PLAiv request. 

Each  of  the  next  three  subsections  is  an  example  that  will  expand  upon  a  portion  of 
the  preceding  paragraph.  Following  is  a  brief  description  of  the  examples  to  be  used. 

(1)  Presented  is  an  example  of  a  PLAN sentence  sent  to  PX,  requesting  a 
process  plan  for  the  specified  part. 

(2)  The  process  plan  is  presented  as  it  would  have  been  originally  output 
to  the  terminal  by  MACHINIST^^.  This  plan  is  not  in  the  form  of  an  FEL 
sentence. 

(3)  Shown  is  the  PLANNED  sentence  returned  in  response  to  the  PLAN 
request.  This  sentence  will  contain  the  process  plan  transformed  into  a 
meaningful  form  (that  is,  feature  lists  of  attribute/ value  pairs). 


2.1.  Requesting  a  Machining  Plan 

If  the  Human  Interface  (Hi)  wanted  a  process  plan  for  machining  the  part,  boss, 
from  the  piece  of  stock,  S0235-,  then  HI  would  need  to  construct,  and  send  to  PX,  an  FEL 


sentence  of  the  form: 

. 

(plan 

(  (name 

G0942) 

(type 

message) 

(to 

px) 

(from 

hi)  ) 

(  (name 

plan_boss) 

(type 

planning_op) 

(application 

planner) 

(environment 

imw) 

(part 

boss) 

(stock 

S0235)  )). 

PX  does  not  need  detailed  information  about  the  part  and  stock  models  from  the 
expert  requesting  a  machining  process  plan.  All  that  is  required  is  the  names  of  the  part 
and  stock  objects,  and  their  location  in  the  modeling  hierarchy.  The  name  of  the  part 
object  is  the  value  of  the  attribute,  part,  and  the  name  of  the  stock  object  is  the  value  of 

14.  Excluding  some  inessential  graphics. 
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the  attribute,  stock.  The  location  of  these  objects  in  the  modeling  hierarchy  is  given  by 
the  values  of  the  attributes:  application  and  environment. 


2.2.  Output  Displayed  by  the  Process  Planner 

The  previous  example  was  of  a  plan  sentence  directed  to  PX.  The  response 
returned  by  PX  is  solely  determined  by  the  outcome  of  the  Process  Plaimer.  If  it  is  not 
possible  to  plan  the  part,  the  response  will  be  a  notplanned  sentence.'  When  the 
Process  Planner  is  able  to  plan  machining  operations  for  the  part,  then  a  planned 
sentence  is  returned.  The  contents  of  this  sentence  are  based  upon  the  plan  output  to 
the  terminal  by  MACHINIST.  For  the  part  currently  under  consideration,  MACHINIST 
produces  the  pl^: 

THE  STOCK  DIMENSIONS: 

3.5  X  2.5  X  1.5 

THE  PLAN: 

Set-Up  #1,  use  VISE 

-  Put  side  1  UP 

-  Put  side  4  DOWN 

-  Put  side  5  ON__SOLID_JAW 
.  -  FACE  MILL  1 


Set-Up  #2,  use  Vise 

-  Put  side  2  UP 

-  Put  side  1  ON_SOLID_JAW 

-  Put  side  5  DOWN 

-  FACE  MILL  2  to  size 


Set-Up  #3,  use  Vise 

-  Put  side  4  UP 

-  Put  side  1  DOWN 

-  Put  side  2  ON  SOLID_JAW 

-  END_MILL  3  to~size 

-  FACE_MILL  4 

-  DRILL  THRUl 


2.2.1.  Explanation  of  Output 

The  process  plan  employs  three  setups  to  machine  the  part,  boss.  An  individual 
setup  provide  (a)  the  fixturing  device  to  use,  (b)  the  orientation  of  the  stock  piece  with 
respect  to  the  bed  of  the  tool  table  and  the  fixtriring  device,  and  (c)  the  features  to  be 
machined. 
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In  the  preceding  plan,  a  vise  is  the  fixturing  device  utilized  in  all  three  of  the 
setups.  A  sine  table  would  be  an  example  of  another  device. 

In  order  to  cut  features,  the  stock  must  be  placed  on  the  tool  table.  For  an 
individual  setup,  the  process  plan  dictates  how  to  orient  the  sides  of  the  stock.  For 
example,  in  setup  #2,  side  5  is  placed  face  down  on  the  tool  bed  (Put  side  5  DOWN), 
and  side  1  is  placed  against  the  solid  jaw  of  the  vise  (Put  side  1  ON_SOLID_JAW). 
Directions  are  also  given  for  orienting  side  2;  however,  that  information  may  be 
ignored,  since  side  2  is  parallel  to  side  5. 


2.3.  PX's  Response  to  PLAN  Sentence 

From  the  information  culled  from  the  process  plan  generated  by  the  MACHENISt 
component  of  PX,  a  planned  sentence  is  constructed  and  returned  to  the  Human 
Interface  (Hi). 


2.3.1.  Feature  List  Ordering  for  Setups  and  Machined  Features 

The  order  of  the  feature  lists  in  the  PLANNED  sentence  is  aitical.  It  is  the  ordering 
of  the  feature  lists  that  determines,  both,  the  ordering  of  the  setups  and  the  ordering  of 
the  features  machined  during  each  setup.  That  is,  when  iterating  through  the  feature 
lists  of  the  PLANNED  sentence,  the  setups  are  executed  in  the  order  in  which  they  are 
read.  This  method  of  ordering  ("executing"  the  feature  list  as  it  read)  also  applies' to  the 
feature  lists  whose  types  designate  a  feature  to  be  machined.  Hopefully,  the  following 
example  will  dear  up  any  confusion.  In  the  PLANNED  sentence  (in  Section  2.3.5), 
setup__47  is  executed  first,  followed  by  setup_49,  then  setup_51.  During 
setup_51,  feature  face_52  is  machined,  followed  by  face_53,  and  finally,  thrul. 


2.3.2.  PLAN3V1NG_0P  Featiure  List 

The  above  discussion  concentrated  on  the  feature  lists  that  pertained  to  setups  and 
nr.achined  features,  but  one  feature  list  precedes  all  of  these.  The  feature  list  in  question 
is  of  type  planning__op.  In  this  feature  list,  the  attribute,  translation,  is  the  only  one 
whose  value  contains  useful  information.  The  value  of  this  attribute,  a  vector’^ 
provides  the  X,  Y,  and  Z  offsets  necessary  to  correctly  translate  the  part  object  within 
the  stock  object.  What  is  meant  by  a  correct  translation?  If  all  of  the  face  features,  given 
in  the  process  plan,  are  removed  from  the  stock  object,  then  the  vertices  of  the  part 
envelope  will  be  equal  to  the  vertices  of  the  modified  stock  object. 


15.  A  vector  is  a  list  with  exactly  three  real  numeric  elements.  In  the  case  of  translation,  the  elements  of 
the  vector  specify  the  translation  in  X,  Y,  and  Z,  respectively. 
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2.3.3.  SEr_l2P  Feature  List 

The  primary  function  of  a  feature  list  of  type  setup  is  (a)  to  give  the  b^ic  fixture 
that  will  be  employed,  and  (b)  provide  information  that  will  allow  other  experts  to 
orient  the  stock  with  respect  to  that  fixture  and  any  other  fixtures^®  employed. 


2.3.3.I.  Attributes  of  Generic  SETJJP  Feature  List 


A  generic  setup  feature  list  consists  of  die  attributes  (ignoring  name  and  type): 


method 


major- ref 


minor-ref 


major-pos 


A  symbol  used  to  designate  the  type  of  fixture  to  be  used  in  this 
setup.  Typical  values  include:  vise,  angle_plate, 
sine_t^le,  siibplate,  or  toe_clamps. 

The  attribute's  value  is  a  face  name  from  die  set  of  face  names 
assigned  to  the  stock  by  MX.  The  face  name  denotes  the  face 
that  the  Process  Planner,  has  designated  as  the  major  reference 
side.  This  is  important  for  probing  operations. 

The  attribute's  value  is  a  face  name  from  the  set  of  face  names 
assigiied  to  the  stock  by  MX.  The  face  name  denotes  the  face 
that  .the  Process  Planner  has  designated  as  the  minor  reference 
side.  This  is  important  for  probing  operations. 

The  value  of  this  attribute  is  used  in  conjunction  with  die  values 
of  the  attributes  ma  jorjref  and  method.  It  specifies  the 
orientation  of  the  face  named  by  ma  jor_ref  with  respect  to  the 
fixture  designated  by  method.  For  example,  the  attribute/value 
pairs: 


(method  vise) 

(major_ref  mx_5) 

(major_pos  on_solid_jaw) 

state  that  face  mx_5  is  to  be  placed  against  the  solid  jaw  of  the 
vise. 


minor  jpos  The  value  of  this  attribute  is  used  in  conjunction  with  the  values 

of  the  attributes  minor_ref  and  method.  It  specifies  the 
orientation  of  the  face  named  by  minor_ref  with  respect  to  the 
fixture  designated  by  method.  For  example,  the  attribute/ value 
pairs: 


(method  vise) 


16.  In  this  context,  the  term  fixtures  is  being  used  loosely.  In  addition  to  what  one  normally  considers  a 
fixture,  indude  the  tool  bed,  a  sine  table,  or  a  subplate. 
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.  (ininor_ref  mx_3) 

(minor_pos  down) 

state  that  face  mx_^3  is  to  be  placed  face  down  in  the  vise. 

xna jor_normal  This  attribute's  value  is  a  vector.,  Specifically,.it  is  the  unit 

normal  vector  of  the  face  denoted  by  the  value  of  the  attribute, 
major_ref. 

xnincrjiormal  'fhe  value  of  this  attribute  is  a  yectbf.  Specifically,  it  is  the  unit 
normal  vector  of  the  face  denoted  by  the  value  of  the  attribute, 
minor_ref. 

x__rotation  A  real  number  that  specifies  the  number  of  degrees  the  model 
must  be  rotated^’'  about  the  x-axis;  such  that,  the  appropriate 
face^®  has.the  unit  normal  vector,  (0  0 1). 

y__rotation  A  real  number  that  specifies  the  number  of  degrees  the  model 
must  be  rotated^^  about  the  y-axis;  such  that,  the  appropriate 
face’®  has  the  unit  normal  vector,  (0  01). 

2__rotation  The  current  version  of  PX  always  considers  (0  0 1)  to  be  the 

•  desired  unit  normal  vector.  Therefore,  no  matter  what  the 

initial  orientation  of  &e  model,  a  rotation  about  the  z-axis  can 
never  bring  about  the  desired  orientation.  Consequently,  The 
value  of  this  attribute  will  always  be  0. 

The  astute  reader  may  have  noticed  that  two  of  the  attributes  given  for  the  feature 
list  of  type  setup,  ma-jor_ref  and  minor_ref,  do  not  appear  to  be  dedudble  from  the 
output  of  the  MACHINIST.  This  information  is  not  concocted  by  PX.  It  is  internal  to  the 
Process  Planner,  but  is  never  displayed  to  the  user.  However,  other  experts  do  require 
this  information;  consequently,  it  is  collected  by  PX,  and  added  to  the  setup  feature  list. 

17.  The  convention  is  adopted  that  positive  rotations  are  such  that,  when  looking  from  a  positive  axis 
toward  the  origin,  a  ninety  degree  counterclockwise  rotation  will  transform  one  positive  axis  into  the 
other.  The  following  table,  usable  for  either  right-handed  or  left-handed  coordinate  systems,  derives 
from  this  convention: 

Axis  of  notation  Direction  of  Positive  Rotation 

X  Y->Z 

Y  Z->X 

Z  X->Y 

18.  By  convention,  a  face  whose  unit  normal  vector  is  (0  0 1)  is  considered  to  face  up.  In  determining 
which  face  should  be  up,  the  first  step  is  to  examine  the  values  of  the  two  attributes  major_po3  and 
minor  jpos,  and  note  which  one  has  a  value  of  either  up  or  down.  Next,  find  the  related  "reference" 
attribute.  Remember,  a  relation  exists  between  the  values  of  the  attributes  major_ref  and 

ma  jor_pos,  and  also  between  the  attributes  minor_ref  and  minor_pos.  Finally,  if  the  value  of  the 
"position"  attribute  is  up,  then  the  value  of  the  corresponding  "reference"  attribute  is  the  lume  of  the 
face  to  be  placed  up.  If  the  value  of  the  "position"  attribute  is  down,  then  the  face  opposite  to  the 
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2.3.3.2.  Additional  Attributes  for  Setup  Employing  a  Sine  Table 

The  preceding  attributes  were  desaibed  as  belonging  to  a  generic  setup  feature 
list  In  other  words,  those  attributes  will  be  found  in  all  feature  lists  of  type  setup, 
regardless  of  the  value  of  the  attribute  method.  However,  if  sine_table  is  the  value 
of  method,  then  there  are  two  addition^  attribute/value  pairs: 

angle  The  value  of  this  attribute,is  a  real  number  which  provides  the 

degree  of  the  angle  that  should  exist  between  the  sine  table  and 
the  tool  bed. 

position  This  attribute's  value  is  one  of  the  tliree  symbols:  X,  Y  or  z.  The 

symbol  denotes  the  axis  to  which  the  hinge  of  the  sine  table  is 
parallel. 

2.3.4.  Feature  Lists  for  Machined  Features 

When  constructing  the  PLANNED  sentence,  PX  views  machined  features  as  falling 
into  two  classes.  Features  that  are  originally  added  to  the  model  (e.g.,  a  thru  hole)  and 
ones  that  are  added  by  the  Process  Planner. 


2.3.4.I.  Original  Features  of  the  Part  Model 

The  first  class,  features  originally  added  to  the  model,  are  trivially  handled  by  PX. 
Adding  a  feature  list  that  describes  machining  features  of  this  class,  requires  no  more 
effort  ^an  giving  the  name  and  type  of  the  feature.  Since  the  MACHINIST  does  not  alter 
anything  that  would  affect  MX's  definition  of  the  feature,  there  is  no  heed  to  provide 
any  other  information.  For  example,  to  desaibe  the  thru  hole,  thru!,  the  feature  list: 

((name  thrul)  (type  thru_hole) ) 


would  suffice. 


value  of  the  corresponding  "reference"  attribute  is  the  face  to  be  oriented  up. 
For  example,  given  the  attribute/value  pairs: 


(niajor_ref 
(ininor_ref 
(ma  jor^jjos 
(minorjpos 


inx_5) 

inx_3) 

on_solid_jaw) 

down) 


the  face  opposite  to  mx_3  will  be  the  face  to  be  placed  up,  since  the  value  of  minorjpos  is  down. 
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2.3A.2.  Face -Features  Added  by  Process  Planner 

Features  added  by  the  Process  Planner  comprise  die  second  class.  The  current 
version  of  MACHINIST  generates  new  features  during  the  process  of  reducing  the  stock 
envelope  to  the  part  envelope  (i.e.,  squaring  the  sto^).  To  reduce  the  stock,  MACMNIST 
specifies  milling  operations.  The  Process  Planner  distinguishes  between  two  types  of 
milling  operations,  face  mills  and  end  mills.  However,  die  Modeler  does  not 
distinguish  between  the  two;  they  are  both  simply  defined  as  face  features  (see  Figure 
4). 


Figure  4.  Definition  of  a  Face  Feature. 

When  PX  detects  one  of  the  milling  operations,  a  feature  list  of  type  face  is  added 
to  the  PLANNED  sentence.  This  feature  list  should  contain  the  information  necessary  for 
MX  to  model  the  feature.  Therefore,  ignoring  name  and  type,  a  face  feature  list 
consists  of  the  attributes: 


face 


p_vector 


1  vector 


w  vector 


The  attribute's  value  is  a  face  name  from  the  set  of  face  names 
assigned  to  the  stock  by  MX.  The  face  name  denotes  the  side 
upon  which  the  milling  operation  will  take  place. 

The  value  of  this  attribute  is  a  vector.  The  origin  is  the  model 
origin.  The  vector  points  to  an  open  comer  of  the  face  that  is  to 
be  machined  away. 

The  value  of  this  attribute  is  a  vector.  The  origin  is  defined  by 
the  value  of  the  attribute,  p_vector.  The  vector  points  along 
an  open  edge  of  the  area  to  be  milled  away. 

This  attribute's  value  is  a  vector.  The  origin  is  defined  by  the 
value  of  the  p_vector  attribute.  The  vector  points  along  an 
open  edge  of  the  area  to  be  machined  away. 
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d_vector  This  attribute's  value  is  a  vector.  The  origin  is  defined  by  the 

value  of  the  attribute,  p_vector.  The  vector  points  along  an 
open  edge  of  the  area  to  be  machined  away.  However,  this 
vector  is  directionally  significant.  It  must  point  toward  the  part 
face. 


2.3.5.  PLANNED  Sentence  for  the  Part,  BOSS 


The  following  PLANNED  sentence  is  the  FEL  translation  of  the  process  plan 
generated  by  MACHINIST  for  the  part,  boss.  This  is  also  the  reply  that  would  be 
generated  for  our  example  PLAi7  sentence. 


(planned 


( (name 

G0942) 

(type 

message) 

(to 

hi) 

(from 

px)  ) 

( (name 

plan_boss) 

(type 

planning_op) 

(application 

planner) 

(environment 

imw) 

(part 

boss) 

(stock 

S0235) 

(translation 

(0.0  0.5  0.25))  ) 

( (name 

setup_47) 

(type 

setup) 

(method 

vise) 

(major_ref 

mx_6) 

(minor_ref 

mx_3) 

(major_pos 

down) 

(minorjpos 

on  solid  jaw) 

(major_normal 

(0.0  0.0  - 

1.0)) 

(minor_normal 

(0.0  1.0 

0.0)) 

(x__rotation 

0) 

(y_rotation 

0) 

(z_rotation 

0)  ) 

( (name 

face_48) 

(type 

face) 

(face 

mx  5) 

(p_vector 

(  3.5  2.5 

1.5)) 

(l_vector 

(-3.5  0.0 

0.0)) 

(w_vector 

(  0.0  -2.5 

0.0)) 

(d_vector 

(  0.0  0.0 

-0.25) 

( (name 

setup_49) 

(type 

setup) 

(method 

vise) 
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(major_ref 

(minor_ref 

(major_pos 

(minor_pos 

(ma jor_normal 

(minor_normal 

(x_rotation 

(y_rotation 

(z  rotation 


mx_5) 

mx_3) 

on_solid_jaw) 

down) 

(0.0  0.0  1.0)) 
(0.0  1.0  0.0)) 
-90) 

0) 

0)  ) 


( (name 
(type 
(face 

face_50) 
face) 
mx  1) 

1.5)) 

(p_vector 

(  3.5 

0.0 

U_vector 

(-3.5 

0.0 

0.0)) 

(w_vector 

(  0.0 

0.0 

-1.5)) 

(d  vector 

(  0.0 

0.5 

0.0) ) 

(  (name 
(type 
(method 
(major_ref 
(minor_ref 
(ma jor_pos 
(minor_pos 
(major_normal 
(minor_normal 
(x_rotation 
(y_rotation 
(z  rotation 


setup_51) 

setup) 

vise) 

mx_5) 

mx_l) 

down) 

on  solid_jaw) 

(0.0  0.0  1.0)) 
(0.0  -1.0  0.0)) 
180) 

0) 

0)  ) 


( (name 

face_52) 

(type 

face) 

(face 

mx  6) 

(p_vector 

(  3.5 

2.5 

0.0)) 

(l_vector 

(  0.0 

-2.5 

0.0)) 

(w_vector 

(-3.5 

0.0 

0.0)) 

(d_vector 

(  0.0 

0.0 

0.25))  ) 

( (name 

face_53) 

(type 

face) 

(face 

rax  2) 

(p  vector 

(  3.5 

0.0 

0.0)) 

(l_vector 

(  0.0 

2.5 

0.0)) 

(w_vector 

(  0.0 

0.0 

1.5)) 

(d_vector 

(-0.5 

0.5 

0.0))  ) 

( (name 

thrul) 

(type 

thru_hole) 

)) 
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This  document  describes  the  syntax  of  PEL  sentences  imderstood  by  the.  Modeling 
Expert  (MX).  It  also  explains  the  interface  between  the  modeler  and  the  program 
(MXD)  ^at  displays  models  on  the  Sun. 

1.  General  EEL  Syntax 

The  usual  syntax  of  EBL  sentences  is  a  parenthesized  list  whose  first  eleinent  is  a  .verb 
and  whose  subsequent  elements  are  feature  lists.. 

( aVerb  featureListl ...  featurelistN ) 

A  feature  list  is  a  parenthesized  list  of  attfibute-yalue  pairs.  An  attribute-value  pair  is  a 
parenthesized  list  of  two  elements:  an  attribute  name  and  a  value. 

( (attributel  valuel) ...  (attributeN  valueN) ) 

In  general,  an  PEL  sentence  should  contain  a  feature  list  that  names  the  sentence  and 
specifies  its  source  and  destination  (usually  the  names  of  experts,  e.g.,  PL,  CX,  MX,  etc.). 
This  feature  list  must  contain  a  TYPE  attribute  with  value  MESSAGE.  Thus,  PEL 
sentences  will  usually  have  the  following  form: 

( aVerb  ( (type  message)  (name  aName)  (from  aSource)  (to  aDestination) ) 
featureList2 

featureListN 

) 

Each  of  the  other  feature  lists  in  a  sentence  should  be  a  complete  and  independent  pack¬ 
et  of  information  for  a  single  application  of  the  verb.  In  other  words,  the  sentence 
above  should  be  equivalent  to  the  following  sequence  of  sentences: 

( aVerb  ( (type  message)  (name  aName)  (from  aSource).  (to  aDestination) ) 
featureList2 

) 


( aVerb  ( (type  message)  (name  aName)  (from  aSource)  (to  aDestination) ) 
featureListN 

) 

This  condition  of  feature  list  independence  is  not  an  absolute  requirement,  but  it  is 
highly  desirable,  because  it  simplifies  the  interpretation  of  individual  sentences. 

It  is  the  primary  purpose  of  this  document  to  describe  the  verbs  and  feature  lists  that 
are  meaningful  to  the  modeler,  and  the  information  that  it  is  currently  capable  of 
providing. 
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2.  Modeler  Hierarchy 

The  basic  thing  to  know  about  the  modeler  is  that  it  organizes  geometry  iri  a  hierarchy: 
worlds,  applications,  environments,  objects,  features^,  and-Taces  (see  Figure  1  on  page  M). 
Worlds,  applications,  environments,  objects,  and  features  are  collections  of  the  dements 
at  the  next  level  down  in  the  hierarchy.  Each  object  is  associated  with  a  TWIN^  BREP 
structure  that  approximates  -the  intended  geometi^  of  thfe  object  Each  face  contdns  a 
connection  with  &e  corresponding  BREP  shucture  Aat  reprisehts  its  geometry. 

Every  element  of  the  hierarchy  is  given  a  name,  which  must  be  tmique  within  the  col¬ 
lection  of  which  the  element  is  a  part.  Thus,  the  names  of  objects  within  a  particular  en- 
yironmenf  must  be  unique,  but  thernaines  may  be ’reused  in  other  environments,  or  at 
other  levels  of  the  hierarchy.  In  order  for  an  raL  sentence  to  refer  to  a  partidilar  node 
in  the  hierarchy,  it  must  specify  the  path  through  the  hierarchy  that  leads  to  that  node. 
For  example,  in  order  for  an  FEL  sentence  to  refer  to  a  particular  o&yVct,  it  must  specify 
the  world,  the  application,  the  environment  and  the  object.  This  is  done  by  giving  the 
name  of  each  of  these  things. 

In  the  current  implementation  of  the  modeler,  there  is  only  one  world  and  it  is  never 
named  explicitly  in  FEL  sentences.  All  applications  are  automatically  part  of  this  de¬ 
fault  world.  Furthermore,  there  is  a  predefined  application  named  "DEFAULT_APP"  and 
it  contains  a  predefined  environment  named  "bEFAULT_ENV";  so  it  is  possible  to  con¬ 
struct  a  simple  model  without  explicit  mention  of  either  an  application  or  an 
environment. 


World 


1.  TWIN  is  a  solid  modeling  package  developed  by  Timothy  Mashbum  at  Purdue  University.  It  is  the 
basis  for  his  Master's  thesis  [Mashburr.  19S7]. 
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3.  Synopsis  of  Modeler  Verbs 

There  are  six  verbs  currently  understood  by  the  modeler: 

Add  The  primaiy  verb  for  creating  and  modifying  a  model.  Five 

types  of  things  can  be  added:  features,  objects,  groups, 
environments,  and  applications. 

Cgpy  Copies  objects  (and  groups)  from  one  environment  to  another 
(possibly  the  same)  environment  and  environments  from  one 
application  to  another  (possibly  the  same). 

Draw  Generates  line  drawing  conunands  to  an  external  display 
program  that  is  connected  to  the  modeler  via  a  Unix  pipe. 
Thi-ee  types  of  things  can  be  drawn:  objects,  groups,  and 
environments.  Scaling  and  translation  can  be  used. 

Get  Retrieves  information  from  the  model  about  all  types  of  things. 

Read  Reads  a  sequence  of  FEL  sentences  stored  in  a  disk  file  and  then 

presents  them  to  the  modeler  as  if  they  were  typed  one  by  one 
on  the  comihand  line. 

Transform  ■  Applies  geometrical  transformations .  to  either  individual 
objects,  groups,  or  to  all  the  objecfe  and  groups  in  an 
environment.  Three  kinds  of  transformations  are  supported: 
translation,  rotation  (in  X,  Y,  and  Z),  and  scaling. 

4.  How  Sentences  are  Processed 

A  single  sentence  can  do  lots  of  work,  because  a  sentence  can  contain  multiple  feature 
lists.  For  example,  a  single  add  sentence  can  add  an  object  to  an  environment  and  then 
add  several  features  to  the  object.  A  transform  sentence  can  transform  several  objects 
and  environments.  A  single  sentence  cannot  both  add  and  transform  an  object,  because 
a  sentence  can  have  only  one  verb. 

4.1.  Order 

Each  sentence  received  by  the  modeler  is  fully  processed  before  work  begins  on  the 
next  one.  The  verb  is  extracted  and  the  indicated  action  is  then  performed  on  each  fea¬ 
ture  list. 

The  feature  lists  are  processed  in  order,  as  they  appear  in  the  sentence.  In  the  case  of  an 
add  sentence,  this  is  necessary  because  the  order  in  which  a  mixture  of  positive  and  neg¬ 
ative  features  are  processed  affects  the  result. 

In  general,  attribute-value  pairs  within  feature  lists  are  not  processed  sequentially,  but 
the  transform  sentence  is  an  exception.  Order  is  significant  when  rotations  about  several 
axes  are  performed,  or  when  translations  and  rotations  are  intermixed  in  order  to  rotate 
an  object  about  a  point  other  than  the  origin.  For  these  reasons,  the  transformation 
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attributes  within  feature  lists  of  a  transform  sentence  are  processed  in  order,  as  they  ap¬ 
pear  in  the  feature  lists. 

4.2.  Defaults 


It  has  already  been  mentioned  that  there  is  a. default  application  and>  within  it,  a  default 
environment.  They  are  created  when  the  modeler  starts  up.  Other  applications  and 
environments  are  created  by  means  of  add  sentences. 

Every  feature- list  must  specify  what  application,  environment,  group  (if  any),  object, 
etc.,  it  is  intended  to  apply  to.  The  modeler  remembers  the  most  recently  specified  ap¬ 
plication,  environment,  group,  and  object;  so  repeated  specification  of  the  same  names 
is  not  necessary. 

5.  The  Add  Verb 

The  add  verb  is  used  to  add  applications,  environments,  groups,  objects  and  features  to 
the  model,  but  the  most  common  use  is  to  add  objects  and  ^oups  to  an  environment 
and  features  to  an  object. 

5.1.  Adding  Objects 

The  following  example  shows  how  to  add  an  object  to  an  environment.  The  TYPE  at¬ 
tribute  specifies  what  kind  of  thing,  in  this  case  an  object,  is  to  be  added  and  the  NAME 
attribute  gives  the  name  which  will  be  used  to  refer  to  this  thing.  The  APPLICATION  and 
ENVIRONMENT  attributes  specify  where  in  the  model  hierarchy  the  new  object  will  exist. 
Currently,  a  new  object  can  only  be  aeated  with  a  rectangular  envelope.  In  a  future 
version  of  the  modeler,  arbitrarily  shaped  envelopes  will  be  allowed. 


(add 

(  (type  object) 

(name  boomerang) 

(application  planner) 

(environment  part_model) 

(p_vector  (0  0  0)) 

(w_vector  (2.5  0  0)) 

(l_vector  (0  6.982  0)) 

(d_vector  (0  0  .25)) 

) 

•  •  • 

) 

5.2.  Adding  Features 

We  can  extend  the  above  example  to  show  how  to  add  a  feature  to  an  object.  Note  that 
"object",  previously  the  value  of  the  TYPE  attribute,  is  now  an  attribute  whose  value  is 
the  name  of  the  object  to  which  the  feature  is  being  added. 


possibly  other  feature  lists 
what  kind  of  thing  is  being  added 
its  name 

the  application  name 
the  environment  name 
the  rectangular  envelope 


(add 

•  •  • 

(  (type  thru_3lot) 


;  possibly  other  feature  lists 
;  what  kind  of  thing  is  being  added 
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(name  facemill) 

(application  planner) 

(environment  part_model) 

(object  boomerang) 

(p_vector  (0  1.7  0)) 

(w_vector  (2.5  0  0)) 

(l_vector  (0  3.582  0)) 

(d_vector  (0  0  .1)) 

) 

•  •  «  ^ 

) 

The  above  example  could  have  been  abbreviated  as  show  below,  because  the  previously 
specified  application,  environment  and  object  names- will  have  become  the  default  val¬ 
ues  for  these  attributes. 

(add 

(  (t3^e  thru_slot) 

(name  facemill) 

(p_vector  (0  1.7  0)) 

(w_vector  (2.5  0  0)) 

(l_vector  (0  3.582  0)) 

(d  vector  (0  0  .1) ) 

) 

«  •  « 

) 

There  are  currently  eleven  features  that  can  be  added  to  an  object  and  they  are  of  two 
kinds:  positive  volume  and  negative  volume.  Adding  a  positive  volume  feature  to  an 
object  adds  volume  to  the  object;  adding  a  negative  volume  feature  removes  volume. 
The  positive  volume  features  include  block,  cylinder,  swept_cylinder,  and  wedge.  The 
negative  volume  features  include  face_mill,  id_circular_profile,  od_drcular_profile, 
thru_slot,  thru_hole,  swept_radius,  and  thru_angle. 

5.2.1.  Block,  Face_Mill,  and  Thru_Slot 

A  block  (or  a  face_mill  or  a  thru_slot)  is  defined  by  four  vectors,  a  position  vector  and 
the  three  vectors  that  form  the  comer  of  the  block  at  that  position.  The  comer  vectors 
determine  the  size  and  shape  of  the  block.  These  four  vectors  are  defined  using  the  at¬ 
tributes  P_VECTOR,  W_VECTOR,  L^VECTOR,  and  D_VECTOR.  The  values  of  ^ese  at¬ 
tributes  are  defined  by  order  triples  of  real  numbers.  Here  is  an  example  definition  of  a 
feature  list  that  desaibes  a  thru_slot  that  is  to  be  aeated.^ 


2.  Recall  tliat  a  feature  list  is  only  meaningful  in  the  context  of  a  sentence  that  begins  with  a  verb,  like 
"(add  ...)". 

It  is  actually  unfortunate  that  new  features  are  described  in  a  manner  so  closely  tied  to  the  underlying 
geometrical  representation.  For  example,  specifying  a  slot  by  length,  wdth,  depth,  and  relative  ^si- 
tion  on  the  part  would  be  much  closer  to  a  "feattme  oriented"  description,  would  be  nnore  natural 
from  the  point  of  view  of  a  designer,  and  would  be  easier  to  interface  with  our  feature  oriented  plan¬ 
ner. 


;  what  kind  of  thing  is  being  added 
;  its  name 

;  parameters  for  a  thru_slot 


;  its  name 

;  the  application-  name 
/  the  environment  name 
7  the  object  name 
;  parameters  for  a  thru  slot 
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(  (type  thru_slot) 

(name  slotl) 

(p_vector  (0  1.7  0)) 
(w_vector  (2.5  0  0)) 
(l_vector  (0  3.582  0)) 
(d  vector  (0  0  .1) ) 


;  feature  type 
;  its  name 
;  position  vector 
;  direction  vector 
;  direction  vector 
;  direction  vector 


5.22.  Blmd_Hole,  Cylinder,  and  Thru_Hole 

A  q^linder  (or  a  thru_hole)  is  defined  by  two  vectors,  a  position  vector  and  an  axis  vec¬ 
tor,  and  a  real  number,  the  radius  of  the  cylinder.  The  position  vector  defines  the  center 
of  one  end  of  the  (circular)  cylinder  and  the  axis  vector  determines  the  length  and  orien¬ 
tation  of  the  cylinder.  The  vectors  are  defined  using  the  attributes  P_VECTOR  and 
D_VECTpR.  The  radius  is  define  using  the  attribute  RADIUS.  Here  is  an  example  defini¬ 
tion  of  a  feature  list  that  describes  a  cylinder. 

(  (type  cylinder)  ;  feature  type 

(name  arm_holder)  ;  its  name 

(p_vector  (1.62  .52  1.35))  ;  position  vector 
(d_vector  (0  0.7  0))  ;  axis' vector 

(radius  .31)  ;  radius  of  cylinder 

) 

5.2.3.  SwepLCylinder  and  Swept^Radius 

A  swept_cylinder  (or  a  swept_radius)  is  defined  by  three  vectors  and  two  real  numbers. 
A  position  vector  (attribute  P_VECTOR)  defines  tlie  center  of  rotation.  Relative  to  the 
center  of  rotation,  ^e  W_VECTOR  attribute  gives  the  center  of  one  end  of  a  cylinder.  An 
axis  vector  (D_VECTOR)  defines  the  orientation  and  length  of  the  cylinder  and  the 
RADIUS  attribute  defines  its  radius  as  a  real  number.  The  attribute  ANGLE  gives  the 
number  of  degrees  through  which  the  cylinder  is  to  be  swept.  Here  is  an  example  defi¬ 
nition  of  a  feature  list  that  describes  a  swept_radius. 


(  (type  swept_radiu3) 
(name  top) 

(p_vector  (.28  .28  0)) 
(w_yector  (.64  0  0)) 
(d_vector  (0  0  .2825)) 
(angle  360) 

(radius  .5) 

) 


feature  type 
its  name 

center  of  rotation 

relative  position  of  cylinder 

axis  vector 

degrees  of  sweep 

radius  of  cylinder 


5.2.4.  ID_Circular_Profile  and  OD_Circular_Profile 

A  circular  profile  feature  describes  a  surface  that  is  an  arc  of  a  cylinder 
(see  Figure  2,  page  58). 
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( 


) 


(typ.e  id_circular_profile) 
(name  inside_radius) 
(p_vector  (.28  .28  0)) 
(r_vector  (.64  6  0)) 
(d_vector  (0  0  .2825)) 
(angle  360) 


;  feature  type 
;  its  name 

;  center  of  rotation 
;  far  edge  of  cylinder 
;  axis  vector 
;  degrees  of  sweep 


5.2.5.  Wedge  and  Thru^Angle 

A  wedge  (or  a  thru_angle)  is  defined  just  like  a  block  or  thru_slot,  but  the  edge  vectors 
are  interpreted  differently. 


5.2.6.  Adding  Groups  (of  objects) 

In  addition  to  simple  objects,  the  modeler  supports  groups  of  simple  objects.  Groups 
can  be  treated  like  simple  objects,  i.e.,  they  can  be  transformed,  copied,  drawn,  etc. 
Groups  also  behave  as  complex  objects  whose  parts  can  be  manipulated  indep^dently. 
Groups  are  added  to  an  environment  in  much  the  way  that  simple  objects  are,  but  there 
is  no  bounding  box  to  be  specified. 


(add 

(  (type  group) 

(neime  toe__clamp) 
(application  holding) 
(environment  setupl) 


;  possibly  other  feature  lists 
;  what  kind  of  thing  is  being  added 
;  its  name 

;  the  application  name 
;  the  environment  name 


) 
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5.3.  Adding  Applications 

An  application  can  be  explicitly  created  as  shown  below.  Because  all  applications  are 
made  part  of  a  single  predefined  world,  only  TYPE  and  NAME  attributes  are  given. 

(add 

{  (type  application) 

(name  planner) 

) 

) 

In  a  future  version  of  the  modeler,  applications  may  be  created  automatically  when 
they  are  first  mentioned. 

5.4.  Adding  Environments 

An  environment  can  be  explicitly  created  as  shown  below.  The  TYPE  and  NAME  at¬ 
tributes  indicate  what  environment  is  to  be  created  and  the  APPLICATION  attribute  tells 
where  in  the  model  it  is  to  be. 

(add 

•  «  « 

(  (type  environment) 

(name  part_model) 

(application  planner) 

) 


;  possibly  other  feature  lists 
;  what  kind  of  thing  is  being  added 
;  its  name 

;  the  application  name 


;  possibly  other  feature  lists 
;  what  kind  of  thing  is  being  added 
;  its  name 


) 

In  a  future  version  of  the  modeler,  environments  may  be  created  automatically  when 
they  are  first  mentioned. 

6.  The  Copy  Verb 

The  copy  verb  duplicates  an  object  or  an  environment,  assigns  the  copy  a  possibly  new 
name,  and  places  it  in  a  possibly  different  environment  or  application.  The  TYPE,  NAME, 
APPUCATION,  and  ENVIRONMENT  attributes  are  used  to  specify  what  is  to  be  duplicated. 
The  TO_APPUCATION,  TO_ENVlRONMENT,  and  TO.OBJECH’  attributes  are  used  to  specify 
where  the  duplicate  is  to  be  located  and  what  it  should  be  called. 

6.1.  Copying  Objects 

Objects  can  be  copied  from  one  environment  to  another  or  duplicated  (with  a  new 
name)  within  a  single  environment.  The  following  example  shows  how  to  copy  an  ob¬ 
ject  to  a  different  environment.  It  says  that  an  object  named  "boomerang"  in  tire  envi¬ 
ronment  "part_model"  of  application  "planner"  is  to  be  copied  with  the  same  name  to 
an.already  existing  environment  named  "part_model2"  of  the  same  application. 
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(copy 


{ 


) 


.  ;  possibly  other  feature  lists 

(type  object)  ;  what  kind  of  thing  is  being  copied 

(name  boomerang)  ;  its  name 

(application  planner)  ;  source  application  name 

(environment  part_model)  ;  source  environment  name 

(to_^application  planner)  ;  destination  application 

(to^environment  part_mpdel2).- 

;  destination  environment 
(to_object  boomerang)  ;  destination  object  name 


) 


Duplicating  an  object  in  an  environment  (i.e.,  when  the  ENVIRONMENT  and 
TO_ENVIRONMENT  attributes  have  the  same  value)  requires  that  the  duplicate  be  given  a 
new  name  (the  value  of  the  TO_OBjECT  attribute). 


6.2.  Copying  Environments 


Environments  can  be  copied  from  one  application  to  another  or  duplicated  (with  a  new 
name)  within  a  single  application.  The  following  example  shows  how  to  duplicate  an 
environment  within  an  application.  It  says  that  an  environment  named  "part_model" 
in  the  application  "planner"  is  to  be  duplicated  and  that  the  duplicate  is  to  reside  in  the 
same  application  imder  the  new  name  "part_model2". 


(copy 


(type  environment)  / 
(name  part_model)  ; 
(application  planner)  ; 
(to_application  planner)  ; 
(to_envi£onment  part_model2) 


possibly  other  feature  lists 
what  kind  of  thing  is  being  copied 
its  name 

source  application  name 
destination  application 

destination  environment 


) 

Duplicating  an  environment  within  an  application  (i.e.,  when  the  APPLICATION  and 
TO_APPLICATION  attributes  have  the  same  value)  requires  that  the  duplicate  be  given  a 
new  name  (the  value  of  the  TO_ENVlRONMENT  attribute). 


7.  The  Delete  Verb 

The  delete  verb  deletes  an  object  from  an  environment  or  an  environment  from  an  appli¬ 
cation.  The  TYPE,  NAME,  APPLICATION,  and  ENVIRONMENT  attributes  are  used  to  specify 
what  is  to  be  deleted. 
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7.1.  Deleting  Objects 

The  following  example  shows  how  to  delete  an  object  from  an  environment. 


(delete 

{  (type  object) 

(name  boomerang) 
(application  planner) 
(environment  part_model) 


;  possibly  other  feature  lists 
;  what  kind  of  thing  is  being  deleted 
;  its  name 
;  application  name 
;  environment  name 


) 

Deleting  an  object  from  an  environment  not  only  removes  the  reference  to  the  object 
from  the  environment,  but  also  destroys  the  object  structure,  its  underlying  features,  as¬ 
sociated  BREP  structures,  etc. 

7.2.  Deleting  Environments 

The  follovdng  example  shows  how  to  delete  an  environment  from  an  application, 
(delete 

(  (type  environment) 

(name  part_model) 

(application  planner) 

> 

♦  •  * 

) 

Deleting  an  environment  from  an  application  not  only  removes  the  reference  to  the  en¬ 
vironment  from  the  application,  but  also  destroys  the  environment  structure,  the  objects 
within  the  environment,  their  features,  etc. 

8.  The  Draw  Verb 

The  draw  verb  causes  a  group  of  display  commands  to  be  sent  to  a  separate  Unix  pro¬ 
cess  via  a  Unix  pipe.  The  primary  application  of  this  verb  is  the  graphic  display  of  an 
environment  of  a  model  on  a  Sun  screen  by  means  of  the  SunCORE-based  MXD  pro¬ 
gram. 

8.1.  Drawing  Objects 

The  following  example  shows  how  to  draw  an  object.  The  TYPE,  NAME,  APPLICATION 
and  ENVIRONMENT  attributes  together  specify  what  is  to  be  drawn.  The  APPUCATION 
and  ENVIRONMENT  attributes  may  be  omitted  if  the  most  recently  used  values  are 
acceptable.  Translation  and  scaling  are  often  needed  to  bring  the  desired  p>ortion  of  the 
model  into  view.  These  transformations  only  apply  to  the  display  and  have  no  effect  on 
the  model  itself. 


;  possibly  other  feature  lists 
;  what  kind  of  thing  is  being  deleted 
;  its  name 
;  application  name 
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(draw 

(  (type  object) 

(name  boomerang) 

(application  planner)' 

(environment  part_model) 

(translation  (0  -.7  0)) 

(scale  (.014  .014  .014)) 

) 

) 

8.2.  Drawing  Environments 

Drawing  an  environment  is  similar  to  drawing  an  object  and  the  same  transformations 
may  be  applied.  ‘Hiere  is,  though,  a  difference  between  drawing  an  environment  and 
drawing  all  the  objects  in  an  environment.  When  an  environment  is-drawm,.the  view¬ 
ing  surface  is  automatically  cleared  before  the  first  object  is  drawn.  When  individual 
objects  are  drawn,  no  clearing  is  done. 

(draw 

«  •  « 

(  (type  environment) 

(name  part_model) 

(application  planner) 

(translation  (0  -.7  6)) 

(scale  (.014  .014  .014)) 

) 

) 

8.3.  Display  Commands 

The  display  commands  generated  via  draw  consist  of  a  sequence  of  lines,  each  contain¬ 
ing  a  single  character  code  followed  by  some  number  of  parameters. 

Qose  Syntax:  C 

Closes  the  SunCORE  "view_surface"  window. 

Draw  Syntax:  D  x  y  z 

Draws  a  line  from  the  "current  position"  to  the  specified  3D  po¬ 
sition  and  updates  the  "current  position". 

Line  Syntax:  L  X2  ^2 

Draws  a  line  from  the  point  (xj  y^  Zj)  to  the  point  (X2 

Move  Syntax:  M  x  y  z 

Moves  the  "current  position"  to  the  specified  3D  point. 

New  Page  Syntax:  N 

Clears  the  SunCORE  "view_surface"  window. 


possibly  other  feature  lists 
what  kind  of  thing  to  draw 
its  name 

the. application  name 
Y  translation 
X,  Y,  Z  scaling 


possibly  other  feature,  lists 
what  kind  of  thing  to  draw 
its  name 

the  application  name 
the  environment  name 
Y  translation 
X,  Y,  Z  scaling 
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Open  Syntax:  0 

Opens  and  initializes  the  SimCORE  "view_surface"  window. 

Scale  Syntax:  S  x_scale  y_scale  z_scale 

Scales  the  drawing  in  each  dimension  by  the  specified  scale  fac¬ 
tor. 

Translate  Syntax:  T  x_offset  y_offset  2_offset 

Translates  the  drawing  in  each  dimension  by  the  specified 
amount. 

Wait  Syntax:  w  time 

.  Wait  for  the  specified  number  of  1 /60th  seconds. 

X  Rotation  Syntax:  X  x_degrees 

Rotates  the  drawing  around  the  X  axis  by  the  specified  number 
of  degrees. 

Y  Rotation  Syntax:  Y  y_degrees 

Rotates  the  drawing  around  the  Y  axis  by  the  specified  number 
of  degrees. 

Z  Rotation  Syntax:  Z  z_degrees 

Rotates  the  drawing  around  the  Z  axis  by  the  specified  number 
of  degrees. 

8.4,  Alternate  Display  Programs 

When  the  modeler  (mx)  is  executed,  the  name  of  an  (optional)  executable  "display"' 
program  may  be  provided  as  an  argument.  For  example,  if  "mxd"  is  the  name  of  such  a 
display  program,  the  modeler  could  be  executed  with  the  following  command. 

%  mx  mxd 

This  display  program  is  executed  as  a  "child"  process  under  the  modeler  and  is  con¬ 
nected  to  the  modeler  via  a  "pipe"  so  that  the  display  process  can  receive  commands 
from  the  modeler  via  the  display  process'  standard  input.  The  commands  that  it  may 
receive  are  described  in  the  previous  section. 

A  display  program  (mxd)  that  produces  perspective  drawings  on  the  Sun  (using  the 
SimCORE  library)  is  currently  available.  Simple  modifications  of  this  program  could 
be  used  to  generate  PostScript  or  types  of  output  from  the  modeler. 

9.  The  Get  Verb 

The  get  verb  is  used  to  retrieve  information  from  the  modeler.  The  format  for  retrieving 
applications,  environments,  objects,  and  features  is  illustrated  in  the  example  below. 
Each  feature  list  specifies  the  type,  name,  and  appropriate  context  of  the  thing  to  be  re¬ 
trieved.  The  amount  and  kind  of  information  supplied  by  the  modeler  depends  on  the 
type  of  thing  requested. 
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9.1.  Application  Request 

When  you  want  to  know  what  environments  are  contained  in  an  application,  you  send 
the  modeler  a  get  message  with  TYPE  "application".  You  specify  the  name  of  the  appli¬ 
cation  you  want  with  the  NAME  attribute.  Here's  how  to  get  a  list  of  environments  in 
the  "planner"  application: 

(get 

(  (type  application) 

(name  planner) 

) 

) 

(got 

(  (type  application) 

(name  planner) 

(world  world) 

(environment  (part 

) 

*  •  • 

) 

The  reply  repeats  the  TYPE  and  NAME  attributes,  tells  you  the  name  of  the  "world"  con¬ 
taining  the  application,  and  gives  the  list  of  environments  as  the  value  of  the 
ENVIRONMENT  attribute.  You  can  use  this  information  to  retrieve  information  about 
each  of  the  environments. 


what  kind-  of  thing  to  get 
its  name 


:_model ) ) 


type  of  thing  retrieved 

its  name 

the  world  name 

list  of  environments  in  this 
application 


9.2.  Environment  Request 

When  you  want  to  know  what  objects  are  contained  in  an  environment,  you  send  the 
modeler  a  get  message  with  TYI’E  "environment".  You  specify  the  name  of  the 
environment  you  want  with  the  NAME  attribute.  You  specify  the  application  containing 
this  environment  with  the  APPLICATION  attribute.  Here's  how  to  get  a  list  of  objects  in 
the  "part_model"  environment: 


(get 

(  (type  environment) 
(name  partjtnodel) 
(application  planner) 

) 

) 

(got 

(  (type  environment) 
(name  part_model) 
(world  world) 


;  what  kind  of  thing  to  get 
;  its  name 

;  the  application  name 


;  type  of  thing  retrieved 
;  its  name 
;  the  world  name 
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(application  planner)  ;  the  application  name 

(object  (boomerang) )  ;  list  of  objects  in  this  environment 

) 

) 

The  reply  repeats  the  TYPE,  NAME,  and  APPLICATION  attributes,  tells  you  the  name  of  the 
"world"  containing  the  application,  and  gives  the  list  of  objects  as  the  value  of  the 
OBJECT  attribute.  You  can  use  this  information  to  retrieve  information  about  each  of  the 
objects. 

9.3.  Object  Request 

When  you  want  to  know  what  features  are  contained  in  an  object,  you  send  the  modeler 
a  get  message  with  TYPE  "object".  You  specify  the  name  of  the  object  you  want  with  the 
NAME  attribute.  You  specify  the  application  and  environment  containing  this  object 
with  the  APPLICATION  and  ENVIRONMENT  attributes.  Here's  how  to  get  a  list  of  features 
in  the  "boomerang"  object: 


(get 

«  •  * 

(  (type  object) 

(name  boomerang) 

(application  planner) 

(environment  part_model) 

) 

•  «  « 

) 

(got 

(  (type  object) 

(name  boomerang) 

(world  world) 

(application  planner) 

(environment  part_model) 

(feature  (envelope  holel)) 

) 

•  •  • 

) 

The  reply  repeats  the  TYPE,  NAME,  APPLICATION  and  ENVIRONMENT  attributes,  tells  you 
die  name  of  the  "world"  containing  the  application,  and  gives  the  list  of  features  as  the 
value  of  the  FEATURE  attribute.  You  can  use  this  information  to  retrieve  information 
about  each  of  the  features. 

9.4.  Feature  Request 

When  you  want  to  know  about  a  particular  feature  in  an  object,  you  send  the  modeler  a 
get  message  with  TYPE  "feature".  You  specify  the  name  of  the  name  you  want  with  the 
NAME  attribute.  You  specify  the  application,  environment,  and  object  containing  this 
feature  with  the  APPUCATION,  ENVIRONMENT,  OBJECT  attributes.  Here's  how  to  get 


type  of  thing  retrieved 

its  name 

the  world  name 

the  application  name 

the  environment  name 

list  of  features  of  this  object 


;  what  Icind  of  thing  to  get 
/  its  name 

/  the  application  name 
;  the  environment  name 


66 


Carnegie  Mellon  University  FEL  Syntax  for  the  IMW  Modeler 

information  about  a  feature  named  "holel": 


(get 

(  (type;  feature)  ;  what  kind  of  thing  to  get 

(name  holel)  ;  its  name 

(application  planner)  ;  the  application  name 

(environment  part_model)  ;  the  environment  name 
(object  boomerang)  ;  the  object  name 

) 

) 

(got 

(  (type  thru_hole)  ;  type  of  thing  retrieved 

(name  holel)  ;  its  name 

(world  world)  ;  the  world  name 

(application  planner)  ;  the  application  name 

(environment  part_model)  ;  the  environment  name 

(object  boomerang)  ;  the  object  name 

) 

«  •  • 

) 

The  reply  repeats  the  NAME,  APPLICATION,  ENVIRONMENT  and  OBJECT  attributes,  tells 
you  the  name  of  the  "world"  containing  the  application,  includes  a  TYPE  attribute  with 
the  specific  type  of  the  feature,  and  gives  other  attribute/value  pairs  appropriate  for 
that  feature. 

The  following  sections  describe  the  special  attribute/ value  pairs  for  each  of  the  features 
supported  by  the  modeler. 

9.4.1.  BREP 

The  BREP  pseudo-feature  gives  a  boundary  representation  of  an  object  and  is  included 
in  the  modeler  for  use  by  the  Holding  Expert,  which  employs  preexisting  algorithms 
that  require  this  kind  of  non-feature-oriented  input.  Three  attributes  are  provided  in 
addition  to  the  standard  ones  that  accompany  all  feature  descriptions. 


(got 

•  •  • 

(... 

(vertex  ( (x^  z^) . . .  {x^  z^^) ) ) 

(loop  I  •.•(vpj^...Vpj^))) 

(face  ( ^  ^ 

) 

•  •  • 

) 
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The  VERTEX  attribute  gives  a  list  of  all  vertices  of  the  object.  A  vertex  is  a  triple  of  real 
numbers  giving  the  x-y-z  coordinates  of  a  point.  Tlie  LOOP  attribute  gives  a  list  of  all 
loops  of  the  object.  A  loop  is  a  sequence  of  vertices  that  describe  a  connected  sequence 
of  edges  on  a  face.  Each  vertex  in  a  loop  is  described  by  an  integer  index  into  the 
VERTEX  list.  The  FACE  attribute  ^ves  a  list  of  all  the  faces  of  the  object.  A  face  is  de- 
SCTibed  by  a  list  of  loops,  the  first  of  which  is  its  outer  boundary;  subsequent  loops  on  a 
face  describe  holes  in  ^e  face.  Each  loop  is  described  by  ah  integer  index  into  the  LOOP 
list. 

9.4.2.  Envelope 

The  ENVELOPE  feature  desaibes  a  rectangular  bounding  box  around  an  object.  Three 
attributes  are  given  in  addition  to  the  standard  ones  that  accompany  all  feature  descrip¬ 
tions:  FINISH,  DISTANCE,  and  NORMAL. 


(got 

{  (finish  ( (side^^  f  . . .  (sideg  f g) ) ) 

(distance  ( (s^^  S2  d^)  (s^  d2)  (s^  Sg  d^))) 

(normal  ( (side^^  (x^^  ) . . .  (sideg  (Xg  yg  Zg) ) ) ) 

) 

) 

The  FINISH  attribute  specifies  the  surface  finish  of  the  sides  of  the  stock.  It  is  given  as  a 
list  of  pairs,  each  of  which  is  composed  of  the  name  of  a  side  and  the  name  of  the  finish 
property  for  that  side.  The  DISTANCE  attribute  specifies  the  distance  between  parallel 
sides  of  the  envelope.  It  is  given  as  a  list  of  thi’ee  triples,  each  of  which  has  two  side 
names  and  the  real  numbered  distance  between  those  sides.  The  NORMAL  attribute  unit 
face  normals  of  the  sides  of  the  stock.  They  are  given  as  a  list  of  pairs,  each  of  which  is 
composed  of  the  name  of  a  side  and  a  vector,  represented  as  a  three  element  list. 

9.4.3.  Thru^Hole 

The  THRU_HOLE  feature  desaibes  a  hole  that  opens  on  two  opposite  sides  of  the  enve¬ 
lope  of  an  object.  Five  attributes  are  provided  in  addition  to  ^e  standard  ones  that  ac¬ 
company  all  feature  descriptions. 


(got 


(  (position  ( (Xj^  y^^  (X2  Y2  ^2^ ) ) 

;  position  on  true  faces  corresponding 
;  to  the  '*opens_on"  sides 
(depth  d)  ;  depth  of  the  hole 

(radius  r)  ;  radius  of  the  hole 

(opens_on  (side^^  side2))  »  envelope  sides 

(distance  ( (side^  distj^)  (side^  dist2))) 

;  distance  from  orthogonal  sides 


) 
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) 

The  POSITION  attribute  gives  the  position  of  the  hole  on  each  of  the  surfaces  that  it 
opens  onto,  in  the  order  that  corresponds  with  the  envelope  sides  given  by  the 
OPENS_ON  attribute.  The  DEnH  attribute  gives  the  depth  of  the  hole  as  a  real  number. 
The  RADIUS  attribute  gives  the  radius  of  the  hole  as  a.  real  number.  The  OPENSJDN  at¬ 
tribute  specifies  the  two  opposite  sides  of  the  envelope  associated  with  the  hole.  The 
DISTANCE  attribute  tells  the  distance  of  the  center  of  the  hole  from  two  orthogonal  sides 
of  the  envelope  of  the  object.^ 

9.4.4.  Biind_Hole 

The  BLIND_HOLE  feature  describes  a  hole  that  opens  on  only  one  side  of  the  envelope  of 
an  object.  Five  attributes  are  provided  in  addition  to  the  standard  ones  that  accompany 
all  feature  descriptions. 


(got 


(  (position  (Xj^  z^)) 

(depth  d) 

(radius  r) 

(opens_on  (side^^) ) 

(distance  ( (side^  dist 


) 


;  position  on  "opens_on"  side 

;  depth  of  the  hole 
;  radius  of  the  hole 
;  envelope  side  the  hole  is  "on" 

(side^  dist2))) 

;  distance  from  orthogonal  sides 


) 


The  POSITION  attribute  gives  the  position  of  the  hole  on  the  surface  that  it  opens  onto; 
this  surface  corresponds  to,  but  may  not  be  identical  with,  the  envelope  side  supplied 
by  the  OPENS_ON  attribute.  Ihe  DEPTH  attribuU  gives  the  depth  of  the  hole  as  a  real 
number.  The  RADIUS  attribute  gives  the  radius  of  the  hole  as  a  real  number.  The 
OPENS_ON  attribute  specifies  the  side  of  the  envelope  associated  with  the  hole.  The 
DISTANCE  attribute  tells  the  distance  of  the  center  of  fhe  hole  from  two  orthogonal  sides 
of  the  envelope  of  the  object.^ 

9.4.5.  Channel  (Thru_Slot) 


The  CHANNEL  feature  describes  a  slot  that  opens  on  three  sides  of  the  envelope  of  an 
object.  Four  attributes  are  provided  in  addition  to  the  standard  ones  that  accompany  all 
feature  desaiptions:  OPENS_ON,  WIDTH,  DEPTH,  and  DISTANCE. 


3.  For  the  cutting  expert,  we  also  supply  the  original  vectors  (possibly  transformed)  used  to  define  this 
feature.  These  vectors  are  the  values  of  the  attributes  P_VECTOR  and  D_VECTOR. 

4.  See  footnote  3. 
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(got 


(  (depth  d) 

(width  w) 

(opens_on  (s^^  .32  s^)) 
(distance  (side  dist),) 


;  depth  of  the  channel 
;  width  of  the  channel 
;  envelope  sides  cut  by  the  channel 

;  distance  from  one  side 


) 

The  POSITION  attribute  gives  the  position  of  the  hole  on  the  surface  that  it  opens  onto; 
this  surface  corresponds  to,  but  may  not  be  identical  with,  the  envelope  side  supplied 
by  the  OPENS_ON  attribute.  'The  DEPTH  attribute  gives  the  depth  of  the  channel  as  a  real 
number.  The  WIDTH  attribute  gives  the  width  of  the  chamtel  as  a  real  number.  The 
OPENS_ON  attribute  specifies  the  three  sides  of  the  envelope  associated  with  the 
channel.  The  DISTANCE  attribute  tells  the  distance  from  one  side  of  the  envelope  of  the 
object  to  the  nearest  side  of  the  channel.® 


10.  The  Read  Verb 


The  read  verb®  allows  input  of  FEL  sentences  from  one  or  more  files,  which  are  specified 
by  the  feature  lists.  This  is  especially  useful  for  loading  models  of  the  relatively  un¬ 
changing  machining  environment.  Each  such  feature  list  must  contain  the  attribute-val¬ 
ue  pair  "  (type  f  iie) "  and  a  pair  with  attribute  NAME  whose  value  is  the  name  of  a  file. 
The  following  sentence  would  cause  two  files  to  be  read  and  the  sentences  in  them  to  be 
processed  before  input  from  jmy  other  source,  such  as  the  network,  is  processed. 

(read 

«  *  • 

(  (type  file)  (name  "model. f el")  ) 

(  (type  file)  (name  "model-transforms.fel")  ) 

•  «  • 

) 


11.  The  Transform  Verb 

The  transform  verb  is  used  to  apply  geometric  transformations  to  one  or  more  objects. 
Translation,  rotation,  and  scaling  are  supported.  Unlike  transformations  applied  with 
the  draw  verb,  these  actually  ^ter  the  coordinates  of  the  vertices  of  the  objects.  Both  en¬ 
vironments  and  individual  objects  may  be  transformed.  Transforming  an  environment 
has  the  same  result  as  individually  applying  the  same  transfonnation  to  all  the  objects 
in  that  environment. 

What  is  to  be  transformed  (either  object  or  environment)  and  what  transformation  (a 
combination  of  translation,  rotation,  and  scaling)  is  to  be  applied  are  specified  by  one  or 
more  feature  lists.  If  an  individual  object  is  to  be  transformed,  then  the  list  should  con- 

5.  See  footnote  3. 

6.  This  is  not,  strictly  speaking,  a  "modeler  verb."  Senteiures  containing  this  verb  are  prwessed  by  the 
Network  tek  in  the  Generic  Expert  and  eure  never  passed  on  to  the  application-speafic  Expert  task. 
So,  the  Model  task  in  the  MX  application  never  sew  such  senteiwres. 
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tain  the  attribute-value  pair  "(t)rpe  object)"  and  a  pair  with  attribute  NAME  whose  value 
is  the  name  of  the  object.  If  an  environment  is  to  be  transformed,  the  TYPE  attribute 
should  have  the  value  "environment".  Here  is  a  t5^ical  transform  sentence. 

(transform 

(  (type  environment)  (name  envl) 

(translation  (1.  1.  0.))  (scale  (2.  2.  2.)) 

) 

(  (type  object)  (name  obj2) 

(translation  (-1.  -1.  0.)) 

(z_rotation  30.) 

(translation  (1.  1.  0.)) 

) 

) 

Translation 

The  TRANSLATION  attribute  takes  a  vector  (i.e.,  a  list  with  exactly  three  real  numeric  ele¬ 
ments)  as  its  value.  The  elements  of  the  vector  specify  the  translation  in  X,  Y,  and  Z,  re¬ 
spectively.  For  example,  the  following  sentence  adds  1  to  the  X  components  and  -2  to 
the  Y  components  of  all  vertices  of  all  objects  in  the  environment  named  "envl". 

(transform 

(  (type  environment)  (name  envl)  (translation  (1.  -2.  0))  ) 

) 

11.2.  Rotation 

There  are  three  rotation  attributes:  X_ROTATION,  Y_ROTATlON,  and  Z_ROTATION.  Each 
takes  a  real  numeric  value  which  specifies  the  number  of  degrees  of  rotation  about  the 
X,  Y,  and  Z  axes,  respectively.  Positive  rotations  are  clockwise  from  the  point  of  view  of 
a  positive  axis,  loolang  towards  the  origin.  The  following  example  rotates  all  the  ob¬ 
jects  in  the  specified  environment  by  90  degrees  about  the  X  axis. 

(transform 

(  (type  environment)  (name  envl) 

(x_rotation  90) 

) 

) 

11.3.  Scaling 

The  SCALE  attribute  takes  a  vector  (i.e.,  a  list  with  exactly  three  numeric  elements)  as  its 
value.  The  elements  of  the  vector  specify  the  scaling  in  X,  Y,  and  Z,  respectively.  The 
following  example  shrinks  all  the  objects  in  the  specified  environment  to  one  fourth 
their  previous  size. 

(transform 

(  (type  environment)  (name  envl) 

(scale  (0.25  0.25  0.25)) 

) 

) 
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1.  Introduction 

This  dcx:ument  describes  the  FEL  interface  to  the  IMW  Holding  Expert.  The  interface  is  a 
mapping  of  the  program  inputs  and  outputs  into  FEL  sentences.  The  holdihg  expert  was. 
developed  by  Kyoung  Kim  and  is  described  in  his  doctoral  thesis  (forthcoming).  This  document 
provides  an  explanation  of  the  input  requirements  and  provides  a  complete  reference  to  the 
messages  the  program  sends  and  receives. 

The  IMW  is  composed- of  several  driferent  expert  systems,  each  with  its  own  area  of  expertise  in 
different  machining  toks.  The  primary  systems  are  for  planning,  holding,  cutting,  sensing, 
modeling  and  execution/control.  In  order  to  achieve  the  goal  of  naachining  a  part,  these  different 
expert  systems  must  exchange  information  and  agree  upon  constraints. 

The  goal  of  the  holding  expert  system  is  to  provide  a  fixnuing  plan  for  a  part  to  the 
execution/control  system  that  will  hold  the  part  securely  during  machining  and  allow  good 
access  to  the  part  for  the  cutting  and  sensing  systems.  The  fixtming  plan  is  a  list  of  fixtures  from 
a  library,  a  sequence  of  NC  programs  for.  the  IMW  novel  tooling  to  place  the  fixtures,  and 
commands  to  update  the  modeler  with  the  changes  in  the  environment  that  the  plan  causes  (e.g., 
so  other  systems  querying  the  modeler  see  that  fixtures  have  been  placed  in  the  environment.) 

To  generate  the  fixturing  plan,  the  holding  expert  needs  several  pieces  of  data.  It  needs  to  know 
the  shape  of  the  part,  the  location  and  orientation  of  the  part  on  the  machine  tool  bed,  and  the 
access  paths  that  the  cutting  system  would  like  to  use. 

The  shape  or  geometry  of  the  part  is  maintained  by  the  modeler.  A  simple  bounding  box  or  part 
envelope  approach  is  not  sufficient  enough  for  the  holding  expert.  Toe  clamps  cannot  be  placed 
on  holes  in  the  part  and  vises  cannot  use  curved  surfaces.  A  complete  description  of  the  part  is 
required  in  order  to  position  fixtures  in  a  rigid,  enor-fi-ee  manner.  The  modeler  maintains  a 
complete  boundary  representation  (BREP)  of  the  part  that  can  be  used  by  the  holding  expert  to 
locate  good  surfaces  for  fixturing. 

The  location  and  orientation  of  the  part  are  determined  by  the  planner.  The  planner  orders  the 
making  of  features  (holes,  shoulders,  slots, ...)  which  determines  the  location  and  orientation  of 
the  part  (e.g.,  on  a  3  axis  milling  machine,  the  side  to  have  a  hole  drilled  in  it  must  be  facing 
"up".)  This  ordering  process  in  the  planner  strongly  impacts  the  flow  of  data  among  the  expert 
systems.  Since  the  planner  orders  features,  several  features  may  be  machined  within  one 
fixturing  setup.  Effectively,  the  entire  system  is  driven  on  a  setup  by  setup  basis. 

The  primary  task  for  the  holding  expert  is  to  plan  the  fixturing  for  each  setup  generated  by  the 
planner.  The  planner  also  can  affect  the  part  location  and  orientation  by  selecting  special 
fixtures  to  aid  in  making  the  part.  The  part  might  be  on  top  of  a' subplate  because  it  is  thin.  The 
part  might  have  an  angled  surface  that  must  be  made  by  mounting  the  part  to  a  sine  table.  The 
use  of  these  methods  must  be  conveyed  to  the  holding  expert.  The  planner  also  knows  which 
part  surface  is  best  to  treat  as  a  reference  surface.  A  reference  surface  is  used  to  accurately 
locate  the  part  (e.g.,  a  milled  surface  is  usually  better  than  a  saw  cut  one.  So  the  milled  surface 
would  be  placed  against  the  locating  pins.)  TTie  planner’s  selection  of  a  reference  surface  must 
also  be  sent  to  the  holding  expert. 

The  cutting  expert  produces  tool  paths  to  produce  the  features  in  each  setup.  Obviously  the 
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fixtures  cannot  interfere  with  the  cutting  paths.  The  cutting  expert  also  selects  tools  and  feeds 
and  speeds.  The  tool  diameter  and  the  horsepower  along  a  cutting  trajectory  impose  force 
vectors  upon  the  p^  that  the  holding  expert  must  negate  in  order  to  hold  the  part  . stable.  Each 
tool  path  and  parameters  must  be  given  to  the  holding  expert  for  each  setup.. 

Although  the  above  paragraphs, describe  the  logical  flow  of  information  in  and  out  of  tlie  holding 
expert,  the  actual  flow  in  the  IMW  systems  is  a  bit  different  The  conttol/execution  system, 
sometimes  referred  to  as  the  plan  manager,  is  collecting  output  from  each  system  for  execution. 
It  has  the  planner  part  location  information  and  the  cutting  expert  tool  paths  ^d  the  "path"  in  the 
modeler  of  the-part-geometry.  (Since  machining  a  part  typically  involves  multiple  setups,  the 
modeler  has  different  models  for  each  setup.  The  modeler  maintains  a  named  hierarchy  of 
models  and  the  control/executioh  system  knows  which  names  correspond  to  each  setup.  These 
names  form  a,  path  that  can  be  given  to  the  holding  expert  to  retrieve  the  part  boundary 
representation  (BREP)  for  the  p^  in  the  current  setup:) 

The  control/execution  system  can  seiid  a  FEL  message  to  the  holding  expert  with  the  above 
informationi  then  the  holding  expert  need  only  query  the  modeler  (using  the  path  from  the 
control/execution  systerh)  to  get  the  BREP.  TTien  the  holding  expert  will  have  all  the  data 
needed  to  produce  a  plan  fixturing  the  current  setup.  This  basic  cycle  of  "control  teUs  holding  to 
plan,  holding  queries  modeler  and  then  produces  a  plan"  is  repeated  for  each  setup  that  the 
planner  generates. 

If  the  holding  expert  can  generate  a  fixturing  plan,  it  will  return  the  plan  to  the  control/execution 
system.  Although  the  plan  contains  an  ordered  list  of  fixtures,  the  important  output  is  actually  an 
NC  program.  The  name  of  a  file  containing  NC  programs  to  physic^ly  place  the  fixtures  at  the 
appropriate  locations  is  returned.  Also  the  geometric  models  of  the  fixtures  to  be  used  are 
moved  to  the  appropriate  place  (in  the  environment  that  the  planner  named  (path))  from  a  library 
of  fixture  models  in  the  modeler. 

The  sections  that  follow  are  a  very  detailed  list  of  the  FEL  sentences  and  their  components  that 
implement  the  interface  described  above.  They  are  intended  to  be  used  as  a  reference  for 
implementation.  They  do  not  explain  functions  and  terms  from  other  systems.  Readers  should 
be  familiar  with  FEL,  the  generic  expert,  and  the  modeling  expert. 

2.  Flow  of  Sentences 

The  basic  flow  of  sentences  in  and  out  of  the  holding  expert  (called  HX)  is  as  follows: 

HX  receives  a  PLAN  a  SETUP  message.  PLAN  messages  are  typically  from  the  plan  manager 
(PL).  The  PLAN  sentence  contains  one  type  SETUP  featurelist  and  zero  or  more  type 
TOOLPATH  featurelists.  The  SETUP  descries  the  location  of  the  part  model  in  the  modeler, 
its  orientation,  reference  sides,  and  the  planner’s  fixturing  methods.  Each  TOOLPATH 
describes  the  cutter  size,  start  and  stop  points  of  the  path,  feed  rate,  horsepower,  and  the  kind  of 
cut. 

Using  the  setup  information  HX  then  sends  a  GET  BREP  message  to  the  modeler  MX.  The 
BREP'is  the  boundary  representation  of  the  part.  The  edges  and  surfaces  of  the  part  are  defined 
in  the  BREP. 
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When  HX  receives  GOT  BREP  from  the  mckieler,  it  converts  the  BREP’s  VERTEX,  LOOP, 
FACE,  and  NORMAL  data  plus  the  TOOLPATHs  into  structures  usable  by  the  main  fixture 
planning  routine  and  calls  it  The  fixture  planning  routine  returns  a  list  of  fixtures  aiid  the  name 
of  a  file.containing  NC  cckle  to  position  the-fixtures. 

HX  then  sends  a  COPY  sentence  and  a  TRANSFORM  sentence  to  MX.  The  COPY  message 
copies  each,  fixture  from  a  library  to  the  current  part  model.  The  TRANSFORM  message  moves 
each  fixture  mto  Ae  correct  position  tmd  orientation  in  the  part  model. 

When  HX  receives  the  COPIED  message  and  then  the  TRANSFORMED  message  back  from 
MX,  it  sends  a  PLANNED  BUILD_SETUP  message  back  to  the  originator  of  the  PLAN 
message  (usually  PL).  (It  should  really  send  back  a  PLAN  SETUP  message,  but  due  to  some 
restrictions  in  the  plan  manager  software,  it  uses  BUILD_SETUP.)  The  PLANNED  message 
contains  a  list  of  the  fixture  names  used  and  the  name  of  the  NC  file. 

Now  HX  is  ready  to  receive  the  next  PLAN  SETUP  message. 

If  any  negated  verbs  (NOTGOTTEN,  NOTCOPIED,  or  NO  1 1 RANS  FORMED)  are  received 
firam  MX  or  the  fixture  planning  routine  cannot  give  a  list  of  fixtures  to  hold  the  part,  a 
NOTPLANNED  message  is  sent  back  to  the  originator  of  the  PLAN  SETUP  message. 

In  the  current  version  of  HX,  version  0.6,  only  one  PLAN  message  at  a  time  will  be  handled. 
PLAN  requests  sent  whUe  planning  is  already  in  progress  will  print  an  error  message  on  the 
terminal  and  will  then  be  IGNORED!  (no  NOTPLANNED  is  sent  back). 


3.  Verbs 


The  holding  expert  accepts  a  very  limited  number  of  FEL  verbs.  The  PLAN  verb  is  the  only 
verb  used  to  command  the  holding  expert  (sent  from  another  expert  or  typed  in  to  the  generic 
expert  terminal  interface.)  All  other  verbs  are  generated  or  are  receiv^  as  replies  from  the 
modeling  expert. 


PLAN 


GOT 

NOTGOTTEN 

COPIED 

NOTCOPIED 


The  PLAN  verb  is  the  primary  input  that  drives  the  holding  expert  It  creates 
a  plan  for  fixturing  a  setup  using  the  information  in  its  featurelists  and  will 
query  the  modeler  for  part  geometry  information.  PLAN  has  two  featurelists 
(TYPES)  Aat  it  uses.  The  first  is  one  type  SETUP  featurelist.  The  second  is 
zero  or  more  type  TOOL_PATH  featurelists.  See  the  Attributes  description 
for  further  details. 

The  GOT  verb  is  the  reply  from  the  modeler  containing  the  part  BREP. 
Only  the  featurelist  type  BREP  is  allowed  here. 

The  NOTGOTTEN  verb  is  the  reply  from  the  modeler  that  the  part  BREP 
was  not  retrieve  do  to  some  error  (Sec  the  Errors  section.)  All  featurelists  of 
this  verb  arc  ignored. 

The  COPIED  verb  is  the  reply  from  the  modeler  that  the  fixtures  have  been 
copied  from  the  library  into  the  current  part  environment.  All  featurelists  of 
this  verb  are  ignored. 

The  NOTCOPIED  verb  is  the  reply  from  the  modeler  that  there  was  an  error 
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copying  the  fixmres.from  the  library  into  the  current  part  environment  (See 
the  Error  section.)  All  feanrrelists  of  this  yerb  are  ignored. 

TRANSFORMED  The  TRANSFORMED  verb  is  the  reply  ffoih  the  modeler  that  the  fixtures 
have  been  transformed  to  the:  correct  location  in  the  current  part 
environment.  All  featurelists  of  this  verb  are  ignored. 

NOTTRANSFORMED 

The  NOTTRANSFORMED  verb  is  the  reply  from  the  modeler  that  there 
was  an  error  transforming  the  fixtures  to  the  correct  location  in  the  current 
part  environment  (See  the  Error  section.)  All  featurelist  of  this  verb  are 
ignored. 

There  are  three  other  verbs  that  the  hplding  expert  accepts:  ADD,  DELETE,  and  INSPEITT. 
These  were  used  in  debugging  during  development  and  will  not  be  documented  here  because 
they  should  not  be  used! 

The  holding  expert  generated  a  very  limited  number  of  fel  verbs.  Only  the  PLANNED  or 
NOTPLANNED  verbs  are  sent  back  to  the  originator  of  the  plan  request.  The  other  verbs  are 
generated  as  requests  to  the  modeling  expert  to  retrieve  or  update  feature  information. 

PLANNED  The  primary  output  of  the  holding  expert  is  return  in  the  PLANNED  verb  to 
the  originator  of  the  PLAN  request  It  has  one  featurelist  type 
BUILD_SETUP  (Due  to  some  limitations  in  the  plan  manager  software,  it 
returns  BUILD_SETUP  instead  of  SETUP.) 

NOTPLANNED  The  NOTPLANNED  verb  is  returned  to  the  originator  of  the  PLAN  request 
whenever- a  plan  cannot  be  made.  This  could  1»  from  an  error  in  the  input 
(PLAN  verb)  or  from  an  incorrect  modeler  environment  or  from  lack  of 
fixtures  for  the  current  part  configuration/size.  This  verb  has  one  featurelist 
type  BUILD_SETUP  (see  BUILD_SETUP  in  the  PLANNED  verb  above) 
which  will  have  an  error  message  in  the  ERRORS  attribute. 

GET  The  GET  verb  is  sent  to  the  modeler  from  the  holding  expert  to  retrieve  part 

geometry  information.  It  has  one  featurelist  type  BREP  which  contains  the 
name  of  the  object,  environment,  and  application  of  the  part. 

COPY  The  COPY  verb  is  sent  to  the  modeler  from  th '  holding  expert  to  copy  the 

fixtures  used  in  the  plan  from  the  fixture  library  to  the  current  part 
environment.  It  contains  one  type  of  featurelist  type  OBJECT  which  will  be 
repeated  for  each  different  fixture  used  in  the  plan. 

TRANSFORM  The  TRANSFORM  verb  is  sent  to  the  modeler  from  the  holding  expert  to 
transform  the  fixtures  (placed  by  the  COPY  verb,  see  above)  into  the  correct 
position  in  the  current  part  environment.  It  contains  one  type  of  featurelist 
type  OBJECT  which  be  repeated  for  each  different  fixture  used  in  the 
plan.  If  the  COPY  verb  could  also  translate  each  object  copied,  this  verb 
would  be  urmecessary. 

Verbs  other  than  those  listed  above  cause  the  holding  expert  to  print  out  a  error  message  and  to 
ignore  the  rest  of  the  sentence.  A  negated  verb  is  not  returned  for  unsupported  verbs. 
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4.  FEL  Types 

Only  a  few  types  (FeatureList  types)  are  accepted  by  the  holing  expert.  The  ones  actually  used 
in  input  sentences  are  SETUP  and  TOOLPATU.  Other  message  types  are  primarily  replies  to 
queries.  The  input  types  are 

SETUP  (in  PLAN)  This  feature  list  contains  all  the  planner  specific  information  required  by  HX 
to  make  a  fixturing  plan.  It  also  contains  the  location  in  the  modeler  (MX) 
that  the  part  boundary  representation  can  be  retrieved  from. 

TOOLPATH  (in  PLAN) 

This  feature  list  contains  the  a  list,  of  tool  paths  generated  by  the  cutting 
expert  (CX)  to  make  the  features  used  in  the  current  setup. 

BREP  (in  GOT)  This  feature  list  contains  the  part  boundary  representation  returned  from  the 
modeler  (MX). 

The  main  Type  (FeatureList  type)  generated  by  the  holding  expert  is  BUILD_SETUP.  It 
contains  the  fixnuing  plan  information.  Other  types  generated  by  the  holding  expert  are  modeler 
operations.  The  types  generated  by  the  holding  expert  are 

OBJECT  (in  GET  and  COPY  and  TRANSFORM) 

This  feature  list  names  the  part  or  a  fixture  to  be  retrieved/manipulated  by 
the  modeler  (MX). 

BUILD_SETUP  (in  PLANNED) 

This  feature  list  contains  the  finished  fixturing  plan  to  be  returned  to  the  plan 
manager. 

The  type  HOLDING_OP  is  accepted  and  ignored.  All  other  types  generate  an  error  message  and 
are  ignored.  Types  returned  from  the  modeling  experts  COPIED/NOTCOPIED  and 
TRANSFORMED/NOTTRANSFORMED  verbs  are  completely  ignored.  Unless  mentioned  as 
optional,  all  attributes  listed  under  each  type  are  required. 

5.  Attributes  for  SETUP  in  PLAN 

The  attributes  for  PLAN  SETUP  messages  contain  the  information  from  the  planner  that  the 
holding  expert  needs  to  generate  a  fixturing  plan.  (The  holding  expert  also  needs  information 
from  the  modeler  and  the  cutting  expert  to  complete  tiie  plan.) 

NAME  The  value  of  this  attribute  is  a  string  which  is  used  to  identify  the  setup.  It  is 

returned  in  the  PLANNED  and  NOTPLANNED  messages. 

APPLICATION  The  value  of  this  attribute  is  a  string  that  names  the  application  in  the 
modeler  that  has  the  part  description. 

ENVIRONMENT  The  value  of  this  attribute  is  a  string  that  names  the  environment  in  the 
modeler  that  has  tiie  part  description. 

PART  The  value  of  this  attribute  is  a  string  that  names  the  object  in  the  modeler  that 

has  the  part  description.  The  obsolete  attribute  OBJECT  if  PART  is. not 
present. 

FINISHED_PART  The  value  of  this  attribute  is  a  string.  Currently  not  used  except  that  it  is 
required  to  be  returned  to  PL. 


79 


Carnegie  Mellon  University 


FEL  Holding  Expert  Interface 


The  value  of  this  attribute  is  an  integer  that  is  unique,  for  each  setup.  Used  to 
generate  unique  NC_FILENAMES. 

The  value  of  this  attribute  is  an  real  in  units  of  degrees  thatds  the  inverse  of 
the  last  X  axis  rotation  applied  to  the  part.  See  the  ANGLE  attribute  below. 

The  value  of  this  attribute  is  an  real  in  units  of  degrees  that  is  the  inverse  of 
the  last  Y  axis  rotation  applied  to  the  part.  See  the  ANGLE  attribute  below. 

The  Value  of  this  attribute  is  an  real  in  units  of  degrees  that  is  the  inverse  of 
the  last  Z  axis  rotation  applied  to  the  part. 

The  value  of  this  attribute  is  a  vector  of  3  reals  that  were  the  last  translations 
applied  to  the  part 

The  value  of  this  attribute  is  a  symbol  that  is  the  name  of  the  suggested 
fixturing  method  from  the  OPS5  planner.  Must  be  one  of  SUBPLATE, 
VISE,  SINE_TABLE,  or  ANGLE_PLATE.  It  is  required,'  but  currently  not 
used  by  main  fixture  planning  routine. 

SUBPLATE_DEPTH 

The  value  of  this  attribute  is  an  real  that  is  the  height  (along  the  Z  axis)  of  the 
subplate  used  in  fixturing.  If  METHOD  SUBPLATE  is  not  used  it  should 
have  the  value  0.0.  The  obsolete  attribute  DEPTH  is  checked  if 
SUBPLATE„DEPTH  is  not  present. 

ANGLE  The  value  of  this  attribute  is  an  real  in  units  degrees  that  is  the  angle  of  the 

sine  table  that  the  part  is  on.  If  METHOD  SINE_TABLE  is  not  used  it 
should  be  the  value  0.0.  When  using  ANGLE,  the  POSITION  attribute 
should  be  set  to  the  axis  of  which  this  angle  of  rotation  is  applied  too. 
WARNING!  It  is  unclear  if  it  is  still  necessary  to  have  one  of  the 
X_ROTATION  or  Y_ROTATION  attributes  set  to  the  inverse  (negation)  of 
angle  so  that  the  axis  can  be  determined. 

POSITION  The  value  of  this  attribute  is  a  symbol  that  is  the  name  of  the  axis  of  rotation 
of  the  ANGLE  attribute.  Must  be  one  of  X,  or  Y. 

MAJOR_NORMAL 

The  value  of  this  attribute  is  a  vector  of  3  reals  that  is  the  unit  normal  vector 
of  the  modeler  envelope  face  that  corresponds  to  the  OPS5  planner’s  major 
reference  face  in  the  current  part  coordinate  system  in  the  APPLICATION, 
ENVIRONMENT,  and  PART(=OBJECT). 

MINOR_NORMAL 

Tlic  value  of  this  attribute  is  a  vector  of  3  reals  that  is  the  unit  normal  vector 
of  the  modeler  envelope  face  that  corresponds  to  the  OPS5  planner’s  minor 
reference  face  in  the  current  part  coordinate  system  in  the  APPLICATION, 
EmTRONMENT,  and  PART(=OBJECT). 

6.  Attributes  for  TOOLPATH  in  PLAN 

Use  of  the  TOOLPATH  featurclist  is  more  complex  than  just  a  list  of  attribute  values.  It  has 
several  different  forms  and  ordering  restrictions.  The  toolpaths  are  a  the  actual  cutter  paths  to 
make  the  part  (specified  in  the  part  model  coordinates.)  Each  request  to  PLAN  a  setup  has  zero 
or  more  type  TOOLPATH  featurelists.  If  none  arc  provided,  then  the  holding  expert  will  make 


SETUP_NO 

X.ROTAtlON 

Y_ROTATION 

Z_ROTATION 

TRANSLATION 

METHOD 
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an  extremely  conservative  fixturing  plan  assuming  that  no  access  to  the  is  needed.  There  are 
four  different  kinds  of  toolpaths:  RAPID,  LINEAR,  TAPPING,  CIRCULAR.  Exactly  one  of 
these  name  must  be  present  in  each.TOOLPATH  featiirelist.  In  every  . PLAN  message,  the  first 
TOOLPATH  featurelist  should  be  a  RAPID  attribute.  The  last  featurelist  should  also  be  a 
RAPID,  but  in  the  current  version  of  HX  this  is  not  checked  for  and  can  be  omitted.  The  RAPID 
attribute  commands  the  machine  tool  to  move  to  a  position  without  cutting.  It  is  used  purely  for 
positioning  the  tool  to  the  place  to  start  cutting.  Each  successive  cut  starts  at  the  place  where  the 
last  cut  left  off.  This  is  why  the  first  TOOLPATH  featurelist  of  each  PLAN  is  a  RAPID,  it  sets 
the  "last"  cutting  position  before  the  first  cut.  The  last  TOOLPATH  featurelist  should  be  a  rapid 
to  home  the  tool  to  a  safe  position.  After  the  initial  RAPID,  any  sequence  of  LINEAR, 
CIRCULAR,  TAPPING,  or  RAPID  is  permitted.  The  LINEAR,  CIRCULAR,  and  TAPPING 
attributes  specify  paths  that  are  actually  cutting  metal.  Each  one  of  these  attributes  start  from  the 
position  the  previous  TOOLPATH  featurelist  left  off  at.  Since  RAPID  does  not  cut  metal,  the 
HORSEPOV^R,  SFM,  and  DIAMETER  attributes  are  ignored  when  RAPID  is  present  The 
HOR.SEPOWER,  SFM,  and  DIAMETER  attributes  are  required  for  the  attributes  that  cut: 
LINEAR,  CIRCULAR,  and  TAPPING.  The  CIRCULAR  attribute  also  requires  center  point  for 
the  circular  paA  to  be  specified  in  the  CENTER  attribute.  See  the  Sample  Sentences  section  for 
some  examples  of  using  TOOLPATHS. 


NAME 

RAPID 

LINEAR 

TAPPING 

CIRCULAR 

HORSEPOWER 

SFM 


The  value  of  this  attribute  is  a  string  which  is  used  to  identify  the  tool  being 
used  in  each  cut.  Currently,  this  attribute  is  not  referenced. 

The  value  of  this  attribute  is  a  vector  of  3  reals  that  set  the  starting  position 
for  the  next  cutter  path. 

The  value  of  this  attribute  is  a  vector  of  3  reals  that  forms  the  end  of  a  linear 
cutting  path.  The  last  cutting  path  position  is  used  as  the  starting  point. 

The  value  of  this  attribute  is  a  vector,  of  3  reals  that  forms  the  end  of  a 
tapping  cutting  path.  Currently,  the  holding  expert  treats  this  identically  to 
the  LINEAR  attribute.  The  last  cutting  path  position  is  used  as  the  starting 
point. 

The  value  of  this  attribute  is  a  vector  of  3  reals  that  forms  the  end  of  a 
circular  cutting  path.  The  last  cutting  path  position  is  used  as  the  starting 
point.  Using  this  attribute  requires  that  a  CENTER  point  for  the  circular 
path  appear  in  this  TOOLPATH. 

The  value  of  this  attribute  is  a  real  that  is  the  maximum  horsepower  used 
during  this  TOOLPATH. 

The  value  of  this  attribute  is  a  real  that  is  the  feed  rate  of  the  tool  table  used 
during  this  TOOLPATH.  If  SFM  is  not  present,  the  obsolete  attribute 
SPEED  is  check  for. 


DIAMETER  The  value  of  this  attribute  is  a  real  that  is  the  diameter  of  the  cutter  used 
during  this  TOOLPATH. 

CENTER  The  value  of  this  attribute  is  a  vector  of  3  reals  that  forms  the  center  point  of 

a  circular  cutting  path.  This  attribute  must  be  present  if  the  CIRCULAR 
attribute  is  used. 


The  are  several  obsolete  attribute  for  TOOLPATHS  that  arc  recognized:  RADIUS,  P_VECTOR, 
and  D_VECTOR.  They  will  not  be  documented  because  they  should  not  be  used. 
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7.  Attributes  for  BREP  in  GET 

The  attributes  in*  the  GET  BREP  (boundary  representation)  message  are  used  to  query  the 

modeler  to  get  BREP  for  the  current  setup.  These  attributes  are  generated  autpmatic^ly  from 

attribute  values  in  the  PLAN  SETUP  message. 

NAME  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 

object  in  the  modeler.  The  yalue  used  is  the  value  of  the  PART  attribute 
fix)m  the  PL^  verb.  This  value  is  the  same  as  the  value  of  the  OBJECT 
attribute. 

APPLICATION  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
application  in  the  modeler.  The  value  used  is  the  value  of  the 
/^PLICATION  attribute  from  the  PLAN  verb. 

ENVIRONMENT  The  value  of  this  attribute  is  a  . symbol  which  is  the  name  of  current  part 
environment  in  the  modeler.  The  value  used  is  the  value  of  the 
ENVIRONMENT  attribute  from  the  PLAN  verb. 

OBJECT  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 

object  in  the  modeler.  The  value  used  is  the  value  of  the  PART  attribute 
from  the  PLAN  verb.  This  value  is  the  same  as  the  value  of  the  NAME 
attribute. 


8.  Attributes  for  BREP  in  GOT 

The  attribute  values  in  the  GOT  BREP  (boundary  representation)  message  are  the  values 

returned  by  the  modeler  from  a  GET  BREP  query.  They  contain  the  part  description  that  the 

holding  expert  uses  to  locate  good  surfaces  for  fixturing. 

NAME  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 

object  in  the  modeler.  The  value  received  is  the  value  of  the  NAME  attribute 
from  the  GET  verb.  This  value  is  the  same  as  the  value  of  the  OBJECT 
attribute. 

APPLICATION  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
application  in  the  modeler.  TTie  value  received  is  the  value  of  the 
APPLICATION  attribute  from  the  GET  verb. 

ENVIRONMENT  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
environment  in  the  modeler.  TTie  value  received  is  the  value  of  the 
ENVIRONMENT  attribute  from  the  GET  verb. 

OBJECT  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 

object  in  the  modeler.  The  value  received  is  the  value  of  the  PART  attribute 
from  the  GET  verb.  This  value  u'  the  same  as  the  value  of  the  NAME 
attribute. 

WORLD  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 

world  in  the  modeler.  This  value  is  not  used. 

VERTEX  The  value  of  this  attribute  is  a  list  of  vectors  of  3  reals  of  the  vertices  of  the 

part  named  by  APPLICATION,  ENVIRONMENT,  and  OBJECT.  It  is 
converted  into  an  array  for  use  by  the  main  fixture  planning  routine. 
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LOOP  The  value  of  this  attribute  is  a  list  of  vectors  of  3  reals  of  the  TWIN  loops  of 

the  part  named  by  APPLICATION,  ENVpiONMENT,  and  OBJECT.  It  is 
converted  into  an  arrays  HOLES  and,  FACES  for  use  by  the  main  fixture 
plarthing  routine. 

FACE  The  value  of  this  attribute  is  a  list  of  vectors  of  3  reals  of  the  TWIN  faces  of 

the  part  named  by  APPLICATION,  ENVIRONMENT,  and  OBJECT.  It  is 
used  to  guide  which  LOOPS  are  converted  into  HOLES  and  into  FACES  for 
use  by  the  main  foture  planning  routine. 

NORMAL  The  Value  of  this  attribute  is  a  list  of  vectors  of  3  reals  of  the  TWIN  face 

normals  of  the  part  named  by  APPLICATION,  ENVIRONMENT,  and 
OBJECT.  It  is  included  in  the  array  of  .'FACES  for  use  by  the  main  fixture 
planning  rou^e. 


9.  Attributes  for  BUILD^SETUP  in  PLANNED 


The  BUILD_SETUP  featurelist  in  PLANNED  is  the  primary  output  of  the  holding  expert.  It 
returns  the  part  rotations  and  translations  and  the  list  of  fixtures  to  use  and  the  name  of  an  NC 
code  file  that  has  commands  for  placing  the  fixtures.  Due  to  some  limitations  in  plan  manager 
software,  it  also  returns  all  the  attributes  sent  down  in  the  PLAN  SETUP  message.  Only 
X_ROTATIpN.  Y.ROTATION,  Z_ROTATION,  TRANSLATION,  NC_FILENAME, 
FIXTURES,  and  MODE  contain  useful,  new  information.  All  other  attributes  of  tliis  sentence 
are  copied  from  the  original  PLAN  sentence. 


NAME 


The  value  of  this- attribute  is  a  symbol  which  is  the  name  of  the  setup  that 
was  planned.  Its  value  is  the  viue  of  the  attribute  NAME  for  SETUP  in 


PLAN. 


X_ROTATION 

Y_ROTATION 

Z_ROTATION 


The  value  of  this  attribute  is  an  real  in  units  of  degrees  that  is  the  X  axis 
rotation  to  be  applied  to  the  part  for  fixttiring  this  setup.  In  the  current 
version  of  HX,  this  value  is  not  used  (always  0.0.) 

The  value  of  this  attribute  is  an  real  in  units  of  degrees  tliat  is  the  Y  axis 
rotation  to  be  applied  to  the  part  for  fixturing  this  setup.  In  the  current 
version  of  HX,  this  value  is  not  used  (always  0.0.) 

The  value  of  this  attribute  is  an  real  in  units  of  degrees  that  is  the  Z  axis 
rotation  to  be  appHed  to  the  part  for  fixturing  this  setup.  In  the  current 
version  of  HX,  this  value  is  the  only  rotation  actually  used,  (X  and  Y  are 
not.) 


TRANSLATION  The  value  of  this  attribute  is  a  vector  of  3  reals  that  are  translations  to  be 
applied  to  the  part  for  fixturing  this  setup.  In  the  current  version  of  HX,  this 
value  is  not  used  (always  (0.0  0.0  0.).) 

NC_FILENAME  The  value  of  this  attribute  is  a  string  that  is  the  name  of  a  file  that  has  the  NC 
code  to  place  fixtures  for  the  current  setup.  This  file  is  generated  for  each 
setup  planned  and  thus  must  have  a  unique  name.  The  name  is  of  the  form 
hx_macro_Numbcr,  where  Number  is  the  value  of  the  SETUP_NO  attribute 
from  SETUP  in  PLAN.  The  file  is  generated  in  the  current  working 
directory  of  the  HX  process,  so  an  absolute  path  (filename  start  with  a  /)  is 
provided. 


83 


Carnegie  Mellon  University 


FEL  Holding  Expert  Interface 


FIXTUE^S  The  value  of  this  attribute  is  a  list  of  symbols  that -the  main -fixture  planning 

routine  choose  to  fixture  the  part  for  the  current  setup.  These  each  of  these 
symbols  have  the  fonn  Name_Number  where  Name  is  one  of  LOCATOR, 
tOE_CLAMP,  F1XED_VISE_JAW,  .MOVEABLE_VISE_JAW, 
_PARALLEL_BAR,  RISER,  BOLT,  SUBPLATE.  Each  type  of  fixtme  is 
uniquely  identified  by  appending  a  number  to  its  name.  If  Ae  fixture  library 
has  three  locators,  they  would  be  referenced  by  LOCATOR_l, 
LOCATOR.!,  and  LOCAT0R_3. 

MODE  The  value  of  this-  attribute  is  a  symbol  that  the  says  whether  the  fixturing 

operations  are  done  autpinatically  or  manually.  Its  value  is  one  of 
MAl^AL  or  AUTOMATIC.  Due  to  limitations  in  plan  manager  software 
this  is  returned  in  BtfiLD.SETUP  always  as  MANUAL.  When  the 
limitations  are  removed,  the  per  fixture  mode  generated  in  the  NC  file  will 
be  used  instead. 

SETUP.NO  The  value  of  this  attribute  is  an.integer  that  is  unique  for  each  setup.  It  is 
Used  to  generate  unique  NC.FILENAMES.  It  is  the  value  of  the 
coiresponding  attribute  from  SETUP  in  PLAN., 

APPLICATION  The  value  of  this  attribute  is  a  string  that  names  the  application  in  the 
modeler  that  has  the  part  description.  It  is  the  value  of  the  coixespondiiig 
attribute  from  SETUP  in  PLAN. 

ENVIRONMENT  The  value  of  this  attribute  is  a  string  that  names  the  environment  in  the 
modeler  that  has  the  part  description.  It  is  the  value  of  the  corresponding 
attribute  from  SETUP  in’ PLAN. 

PART  The  value  of  this  attribute  is  a  string  that  names  the  object  iii  the  modeler  that 

has  the  part  description.  It  is  the  value  of  the  corresponding  attribute  from 
SETUP  in  PLAN. 

FINISHED.PART  The  value  of  this  attribute  is  a  string.  It  is  currently  not  used.  It  is  the  value 
of  the  corresponding  attribute  from  SETUP  in  PLAN. 

ANGLE  The  value  of  this  attribute  is  an  real  in  units  degrees  that  is  the  angle  of  the 

sine  table  that  the  part  is  on.  See  SETUP  in  PLAN  for  more  information 
about  its  use.  It  is  the  value  of  the  corresponding  attribute  from  SETUP  in 
PLAN. 

SUBPLATE.DEPTH 

The  value  of  this  attribute  is  an  real  that  is  the  height  (along  the  Z  axis)  of  the 
subplate  used  in  fixturing.  It  is  the  value  of  the  corresponding  attribute  from 
SETUP  in  PLAN. 

POSITION  The  value  of  this  attribute  is  a  symbol  that  is  the  name  of  the  axis  of  rotation 
of  the  ANGLE  attribute.  Must  be  one  of  X,  or  Y.  It  is  the  value  of  the 
corresponding  attribute  from  SETUP  in  PLAN. 

METHOD  The  value  of  this  attribute  is  a  symbol  that  is  the  name  of  the  suggested 

fixturing  method  from  the  OPS5  planner.  Must  be  one  of  SUBPLATE, 
VISE,  SINE_TABLE,  or  ANGLE.PLATE.  It  is  the  value  of  the 
corresponding  attribute  from  SETUP  in  PLAN.  If 'no  method  is  sent  in  the 
PLAN  message,  the  symbol  NONE  will  be  returned. 
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10.  Attributes  for  BUILD_SETUP  in  NOTPLANNED 

The  NOTPLANNED  BUILD_SETUP  message  is  returned  when  there  is  an  error  planning  a 

setup.  The  attributes  of  this  message  describe  the  error  that  occurred. 

NAME  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  the  setup  that 

was  not  successfully  planned.  Its  value  is  the  value  of  the  attribute  NAME 
for  SETUP  in  PLAN. 

ERRORS  The  value  of  this  attribute  is  a  string  describing  the  error  that  occurred  in 

attempting  to  create  a  plan.  See  the  section  on  Errors  and  Warnings  for  a  list 
of  strings. 

11.  Attributes  for  OBJECT  in  COPY 

The  COPY  OBJECT  message  updates  the  current  setup  in  the  modeler  with  the  fixtures  that  will 

hold  the  part.  The  attributes  of  this  message  name  the  fixtures  from  a  standard  fixturing  library 

and  the  current  setup  environment.  Each,  type  OBJECT  feamrelist  in  a  COPY  sentence  contains: 

NAME  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  a  fixture  that  is 

to  be  copied  from  the  fixture  library  to  the  current  part  environment.  These 
names  have  the  form  Name_Number  where  Name  is  one  of  LOCATOR, 
TOE^CLAMP,  FDCED_VISE_JAW,  MOVEABLE_VISE  JAW, 
PARALLEL_BAR,  RISER,  BOLT,  SUBPLAIB.  Each  type  of  fixture  is 
uniquely  identified  by  appending  a  number  to  its  name.  If  the  fixture  library 
has  three  locators,  they  w'ould  be  referenced  by  LOCATOR  1, 
LOCATOR_2,  and  LOCATOR_3. 

APPLICATION  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  the  application  in 

the  modeler  which  has  the  fixture  library.  Li  the  current  version  of  HX  this 
is  always  LIBRARY. 

ENVIRONMENT  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  the  environment 
in  the  modeler  which  has  the  fixture  library.  Li  the  current  version  of  HX 
this  is  always  PIXELS. 

TO.APPLICATION 

The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
application  in  the  modeler.  The  value  used  is  the  value  of  the 
APPLICATION  attribute  from  the  PLAN  verb. 

TO.ENVIRONMENT 

The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
environment  in  the  modeler.  The  value  used  is  the  value  of  the 
ENVIRONMENT  attribute  from  the  PLAN  verb. 


12.  Attributes  for  OBJECT  in  TRANSFORM 

The  TRANSFORM  OBJECT  message  updates  the  position  of  the  fixtures  (created  by  the  COPY 
OBJECT  message)  in  the  current  setup  in  the  modeler.  The  COPY  OBJECT  message  cannot 
position  the  fixtures,  so  the  TRANSFORM  message  is  used  to  correct  the  positions.  The 
attributes  of  this  message  name  the  fixtures  and  their  locations.  Each  type  OBJECT  featurelist  in 
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a  TRANSFORM  sentence  contains: 

NAME  The  value  of  this  attribute  is  a  symbol  which  is  *e  name  of  a  fixture  :that  is 

to  be  translated  to  its  find  position.  See  the  NAME  attribute  for  OBJECT  in 
COPY  for  a  description  of  its  values. 

APPnCATION  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
application  in  the  modeler.  The  value  used  is  the  value  of  the 
APPLICATION  attribute  from  the  PLAN  verb.  Obviously  this  is  the  same 
as  the  value  of  the  TO_APPLICATION  in  the  corresponding  COPY 
sentence. 

ENVIRONMENT  The  value  of  this  attribute  is  a  symbol  which  is  the  name  of  current  part 
environment  in  the  modeler.  The  value  used  is  the  value  of  the 
ENVIRONMENT  attribute  from  the  PLAN  verb.  Obviously  this  is  the  same 
as  the  value  of  the  TO_ENVIRONMENT  in  the  corresponding  COPY 
sentence. 


Z.ROTATION  The  value  of  this  attribute  is  an  real  in  units  of  degrees  that  is  the  Z  axis 
rotation  to  be  applied  to  the  fixture  object  to  correctly  orient  it  in  the  current 
part  model. 

TRANSLATION  The  value  of  this  attribute  is  a  vector  of  3  reals  that  is  the  translations  to  be 
applied  to  the  fixture  object  to  correctly  position  it  in  the  current  part  model. 


13.  Sample  Sentences 

Listed  below  are  four  sample  files  tool.dc.l,  tool.dc.2,  tool.dc.3,  and  tool.dc.4  approximating  the 
four  setups  for  an  IMW  test  part. 

File  tool.dc.1 

On  the  first  setup  just  simple  face  milling  on  the  top  surface  is  done. 

(plan  ( (type  satup) {nasM  fool) 

(part  objl)  (application  appl)  (anvironioant  anvl) 

(finlshad__part  none) 

(method  none) 

(setup__no  1) 

(angle”" 0) 

(sidTplatejdepth  0) 

(trannlatlon  (0  0  1.25)) 

(x__rotation  -90) 

(y^rotation  0) 

(x__rotation  0) 

(majcr_normal  (0  1  0) ) 

(majorjpes  0) 

(ininor__s;oanal  (0  10))  ;  variable 

(minor jpos  0) 

) 

( (type  tooljpath) (name  tooll) 

(rapid  (-.5  .25  1.135)) 

) 

( (type  tool_path) (name  tooll)  ;  facemill 
(sfm  300) 

(horsepower  3) 

(diameter  0.6) 
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(linear  (3  .25  1.135)))) 

File  tool.dc.2 

On  the  second  setup  the  is  flipped  over  and  the  other  face  is  nulled  and  exposed  edges  are 
edge  milled.  A  channel  or  slot  in  the  center  of  the  part  is  milled. 

(plan  ( (type  setup) (name  fool) 

(part  obj2) (application  app2) (environment  env2) 

(finishedjpart  none) 

(method  none) 

(setup__no  2) 

(angle  0) 

(subplate__depth  0) 

(translation  (0  0  0)) 

(x_rotation  0) 

(y_rotation  0) 

(*_rotation  0) 

(major_normal  (0  1  0)) 

(major_poa  0) 

(minor_nonaal  (0-10))  ;  variable 

(minor_poa  0) 

) 

( (type  tool_pnth) (name  tooll) 

(rapid  (-.2  -.5  -.5)) 

) 

( (type  tool_path) (name  tooll)  ;  endmill 
(sfm  300) 

(horsepower  3) 

(diameter  0.6) 

(linear  (-.2  1.5  -.5))) 

( (type  tool_path) (name  tool2) 

(rapid  (-.5  .6  .42)) 

) 

( (type  tooljpath) (name  tool2)  ;  facemill 
(sfm  300) 

(horsepower  3) 

(diameter  1.5) 

(linear  (3  .6  .42))) 

( (type  tool_path) (name  tool3) 

(rapid  (1.25  -.5  .25)) 

) 

( (type  tool_path) (name  tool3)  ;  millslot 
(sfm  300) 

(horsepower  3} 

(diameter  1.5) 

(linear  (1.25  1.5  .25))) 

) 

File  tool.dc.3 

On  the  third  setup  the  remaining  end  and  face  milling  is  done  and  two  holes  are  drilled. 

(plan  ( (type  setup) (name  fool) 

(part  obj3) (application  app3) (environment  env3) 

(finishedjpart  none) 

(method  none) 

(setupjno  3) 

(amgle  0) 
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( subplat e_depth  0) 

(translation  (0  0  0)} 

(x_rotation  0) 

"(y__rotation  0) 

(z__rotation  0) 

(jnajor_noxmal  (0  1  0} } 

(aiajor_pos  0) 

(minor__nonnal  (0-10))  ;  ▼arlable 

(minor_pos  0) 

) 

( (type  tooljpath) (name  tooll) 

(rapid  (-.2  -.5  -.5)) 

) 

( (type  tool_path) (name  tooll)  ;  endmill 
(s£a  300) 

(horsepower  3) 

(diameter  0.6) 

(linear  (-.2  1.5  -.5))) 

( (type  tool_path) (name  tool2) 

(rapid  (0.25  .57  .34)) 

) 

( (type  toQl_path} (name  tool2)  ;  facemill 
(s£m  300} 

(horsepower  3) 

(diameter  .3} 

(linear  (3  .6  .34)}} 

( (type  tooljpath) (name  tool3} 

(rapid  (.25  .6  .34)) 

) 

( (type  tool_path} (name  tool3)  ;  drill  1 
(sfm  300} 

(horsepower  3} 

(diameter  1.5} 

(linear  (.25  .€  -.5))) 

((type  tooljpath) (name  tool4} 

(rapid  (2.25  .6  .34)) 

) 

( (type  tooljpath) (name  tool4)  ;  drill  2 
(sfm  300} 

(horsepower  3} 

(diameter  .3) 

(linear  (2.25  .6  -.5))) 


File  tooI.d<^4 

On  the  fourth  (and  final)  setup  the  part  is  mounted  on  a  sine  table  at  30  degrees.  The  edge 
overhanging  the  table  is  both  end  milled  and  face  milled  to  produce  a  beveled  edge. 

(plan  ((typ*  satup) (naan  foo4) 

(part  obj4) (application  app4} (anwironmant  anT4} 

(finishadjpart  none) 

(mathod  none) 

(satup  no  4} 

(angla’"30) 

(position  z) 

(subplate__depth  0) 

(translation  (00  .5)} 
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(x_rotatioii  -30) 

(y_rotation  0). 

(z__rotatioii  0) 

(iaajor_normal  (0  1  0)), 

(majorjpos  0) 

(minor_nozmal  (0  0.8660  -.5),)  ;  variable 

(minor_pos  0) 

) 

( (type  tool_path) (name  tboll) 

(rapid-  (  -.5  .2  .8)  ) 

) 

( (type  tool_path) (name  tooll)  ;  facemill 
(afm  300) 

(horsepower  3) 

(diameter  0.6) 

(linear  (2.8  .2  .8))) 

((type  tool_path) (name  tool2) 

(rapid  (-.5  -6.1  .2)) 

) 

( (type  tool_path) (name  tool2)  ;  endmill 
(s£m  300). 

(horsepower  3) 

(diameter  0.6) 

(linear  (2.8  -0.1  .2)) 

) 


After  loading  in  the  fixture  library  and  loading  .in  the  part  into  APP/ENV/OBJ  1  through  4  in  the 
modeling  expert  MX,  the  above  files  can  be  read  into  the  holding  expert  HX  to  produce  the 
following  output:  (The  user  input  is  underlined.  Some  long  lists  of  part  coordinates  have  been 
omitted  from  the  output.) 

%  hx 


>  Starting  HX  version  0 . 6 


>  (read  ((type  file)(name  "tool.dc.1"))) 

(Holding)  Error  in  Setup: :AttzMethod:  bad  method  NOHB  received 
(Output: : send)  '(GET  ( (NAME  GO)  (TYPE  MESSAGE)  (TO  mx)  (FROM  hx)  )  ( (T 
YPB  BREP)  (APPLICATION  APPl)  (ENVIRONMENT  ENVl)  (OBJECT  OBJl)  (NAME  OB 
Jl)  )  )'  (131) 

Fixture  plan  with  toeclasps  or  a  vise  may  exist 
xcmin  xcmax  zcmin  zcmax  0.000  2.750  0.000  1.085 

xvmin  xvmax  -10.000  10.000 

***  Fixture  with  a  vise  *** 
xdist  from  left  end  of  solid  jaw  »  -0.375 
distance  between  jaws  >■  0.700 

***  No  parallel  bar  is  needed  *** 

Name  Size  X  Y  Z 


flxed__vise  jaw  5.868  3.293  0.000 

part  4.493  4.493  0.000 
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inoveable_vise__jaw 


5.868  5.193  0.000 


(Output: ; send)  '(COPY  ( (NAME  Gl>  (TYPE  MESSAGE)  (10  mx)  (FROM  hx)  )  (( 

TYPE  OBJECT)  (NAME  FIXED_VISE_JAW_1)  (APPLICATION.  LIBRARY)  (ENVIRONMEN 
T  PIXELS)  (TO_APPLICATIOM  APPl)  (TO_ENViRONMENT  ENVl)  )  ( (TYPE  OBJECT) 
(NAME  MOVEABLE_VISE_JAW__l)  (APPLICATION  LIBRARY)  (ENVIRONMENT  PIXELS) 
(TO_APPLICATION  APPl)  (TOJENVIRONMENT  BNVl)  )  ) '  (312) 

(Output: : send)  '  (TRANSPOBm”(  (NA5)!E  G2)  (TYPE  MESSAGE)  (TO  mx)  (Pk)M  hx) 

)  ((TYPE  OBJECT)  (NAME  PiXED__VISE_JAW^l)  (APPLICATION  APPi)  (ENVIRONM 
ENT  ENVl)  (Z_ROTATION  0.000000)  (TRANSLATION  (5.867600  3.292600  (>.0000 
00  ) )  )  ( (TYPE  OBJECT)  (NAME  MOVEABLE_VISE_JJW_l)  (APPLICATION  APPl)  ( 
ENVIRONMENT  ENVl)  (Z_ROTATION  0.000000)  (TRANSLATION  (5.867600  5.19260 
0  0.000000  ))  )  )'  (351) 

(Output: : send)  '(PLANNED  ( (NAME  NONE)  (TYPE  MESSAGE)  (TO  none)  (FROM  n 
one)  )  ((NAME  pool)  (TYPE  :BDILD__SETUP)  (XJtOTATlON  0.000000)  (YJROTATI 
ON  0.000000)  (Z_ROTATION  180.000000)  (TRANSLATION  (0.000000  0.000000  0 
.000000))  (SETUPJWO  1)  (APPLICATION  APPl)  (ENVIRONMENT  BNVl)  (PART  OB 
Jl)  (FIN1SHED_PART  NONE)  (ANGLE  0.000000)  (SUBPLATEJDEPTH  0.000000)  (P 
OSITION  X)  (MODE  MANUAL)  (METHOD  NONE)  (NCJTILEKAMB  ’*/ssdh/usr2/baird/ 
imw/hx/doc/exanple/hx_jnacro_l")  (FIXTURES  (FiXED_VISE__JAW_l  MOVEABLEJV 
ISE_JAW_1  ))  )  )'  (490)  “  ~ 

no  such  name  'none'  for  Send 


>  (read  ((type  fileKname  ”tool.dc.2"))) 

(Holding)  Error  in  Setup: :AttrMethod:  bad  method  NONE  received 
(Output: : send)  '(GET  ((NAMEG3)  (TYPE  MESSAGE)  (TO  mx)  (PROM  hx)  )  ( (T 
YPE  BREP)  (APPLICATION  APP?,)  (ENVIRONMENT  ENV2)  (OBJECT  OBJ2)  (NAME  OB 
J2)  )  )'  (131) 

Fixture  plan  with  toeclasps  or  a  vise  may  exist 
xcmin  xcmax  zcmin  zcmax  0.300  2.700  O.COO  0.200 

xvmin  xvmax  0.300  10.000 

***  Fixture  with  a  vise  *** 
xdist  from  left  end  of  solid  jaw  =  -0.300 
distance  between  jaws  «  1.335 

***  A  parallel  bar  is  needed  *** 
max^mim  length^  2.300 
Mximum  widths  1.035 
minimum  heights  0.738 


Name 

Size 

X 

Y 

Z 

fixed__vise_jaw 

5.793 

3.293 

0.000 

parallel^bar 

4.493 

4.493 

0.000 

part 

4.493 

4.493 

0.000 

movesbla_vise__jaw 

5.793 

5.828 

0.000 

(Holding)  Naming  in  SendPlan:  -no  tranfozmation  matrix 

(Output: : send)  '(COPY  ((NAHBG4)  (TXPE  MESSAGE)  (TO  mx)  (FROM  1»)  )  (( 
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TYPE  OBJECT)  (NAME  PIXED_VISE_JAW_1)  (APPLICATION  LIBRARY)  (ENVIROroiEN') 
T  PIXELS)  (TO_APPLICATION  APP2)  (TOj_ENVIRONMENT  ENV2)  )  ( (TYPE  OBJECT) 
(NAME  PARAiiLEL^BAR_l)  (APPLICATION  LIBRARY)  (ENVIRONMEOT  PIXELS)  (TO_ 
APPLICATION  APP2)  (TO_ENVIRONMENT  ENV2),  )  ((TYPE  OBJECT^  (Ni^  MOVEABL 
E_VISE_JAW_1)  (APPLICATION  LIBRARY)  (ENVIRONMENT  PIXELS)  (TO_APPLICATI 
ON  APP2)  (TOJB^RONMENT  ENV2)  )  ) '  (438) 

(Output: : send)  '  (TR^SPORM  ((NAME  65)  (TYPE  MESSAGE)  (TO  nx)  (PROM  hx) 

)  ( (TYPE  OBJECT)  (NAME  PIXEDjVISB_JAW_l)  (APPLICATION  APP2)  (ENVIRONM 
ENT  ENV2)  (ZJROTATION  0.000000)  (TRANSLATION  (5.792600  3.292600  0.0000 
00  ) )  )  ( (TYPE  OBJECT)  (NAME  PARAL1£L_BAR__1)  (APPLICATION  APP2)  (ENVIR 

ONMSNT  ENV2)  (ZJROTATION  0. 000006)  (TRANSLATION  (4.492600  4.492600  0.0 
00000  ))  )  ((TYPE  OBJECT)  (NAME  MOVEABLE_VISE_JAW_l)  (APPLICATION  APP2 
)  (ENVIRONMENT  ENV2)  (Z_ROTATION  0.000000)  (TRANSLATION  (5.792600  5.82 
7600  0.000000  ))  )  )'  (494) 

(Output: : send)  '(PLANNED  ( (NAME  NONE)  (TYPE  MESSAGE)  (TO  none)  (PROM  n 
one)  )  ((NAME  POOij  (TYPE  BDILD_SBTUP)  (X_ROTATi6n  0.000000)  (YJROTATI 
ON  0.000000)  (ZJROTATION  0.000000)  (TRANSLATION  (0.000000  O.OOOOOO  0.0 
00000  ))  (SETTTPJNO  2)  (APPLICATION  APP2)  (ENVIRONMENT  ENV2)  (PART  0BJ2 
)  (PiNISHED_PART  NONE)  (ANGLE  0.000000)  (SUSP LATE  JJEPTH  0.000000)  (POS 
ITION  X)  (MODE  MANUAL)  (METHOD  NONE)  (NC_PILENAME  •7ssdh/usr2/baird/im 
w/hx/doc/exan5)le/hx_inacro_2")  (PIXTORES  (PIXED_VISE_JAW;_1  PARALLEL^BAR 
_1  MOVEABLE_VISE_JAW_l  ) )  )  ) '  (503)  “ 

no  such  name  'none'  for  Send 


>  (read  ((type  file)(name  "tool.dcJ"))) 

(Holding)  Error  In  Setup: :AttrMathod:  bad  method  NONE  received 
(Output: : send) .' (GET  ( (NAME  G6)  (TYPE  MESSAGE)  (TO  mx)  (PROM  hx)  )  ( (T 
YPE  BREP)  (APPLICATION  APP3)'  (ENVIRONMENT  Et3V3)  (OBJECT  OBJ3)  (NAME  OB 
J3)  )  )'  (131) 

Plxture  plan  with  toeclasps  or  a  vise  may  exist 
xcmin  xcmax  zcmin  zcmax  0.300  2.600  0.000  0.290 

xvmin  xvmax  0.300  10.000 

***  Pixture  with  a  vise  *** 
xdist  from  left  end  of  solid  jaw  »  -0.300 
distance  between  jaws  =  1.335 

***  A  parallel  bar  is  needed  *** 
maximum  length^  2.200 
maximtim  widths  1.035 
minimum  heights  0.647 


Name 

Size 

X 

Y 

Z 

fixed_yise_jaw 

5.793 

3.293 

0.000 

paralleljbar 

4.493 

4.493 

0.000 

part 

4.493 

4.493 

0.000 

moveablejv‘ise_  j  aw 

5.793 

5.828 

0.000 

(Holding)  Naming  in  i 

SendPlan:  no 

tranformation  matrix 

(Output : : send)  ' (COPY 

((NAME  G7) 

(TYPE  MESSAGE) 

(TO  mx) 

(FROM  hx) 

TYPE  OBJECT)  (NAME  P1XED_VISE_JAW_1)  (APPLICATION  LIBR.ARY)  (ENVIRONMEN 


91 


Carnegie  Mellon  University 


PEL  Holding  Expert  Interface 


T  FIXELS)  (TO  APPLICATION  A?P3)  (TO^BNVIRONMENT  ENV3)  )  ((TYPE  OBJECT) 
(NAME  PARALIJEL  BAR_1)  (APPLICATION  LIBRARY)  (ENVIRONMENT  PIXELS)  (Tq_ 
APPLICATION  APP3);  (TO_ENVIRONMENT  ENV3),  )  ( (TYPE  OBJECT)  (NAME  MOVEABL 
EJVISE_JAW_1)  (APPLICATION  LIBRARY)  (ENVIRONMENT  PIXELS)  (TO_APPLICATI 
ON  APP3)  (TOJENVIRONMENT  ENV3)  )  ) '  (.438) 

(Output:  :8«nd)  '  (TRANSFORM  ((NAME  G8)  (TYPE  MESSAGE)  (TO  mz)  (PROM  hz) 

)  ((TYPE  OBJECT)  (NAME  PIXED_VISE_JAW_1)  (APPLICATION  APP3)  (ENVIRONM 
ENT  ENV3)  (Z_ROTATION  O.OOOOO'O)  (TRANSLATION  (5.792600  3.292600  0.0000 
00  ))  )  ((TYPE  OBJECT)  (NAME  PARALLEL_BAR_1)  (APPLICATION  APP3)  (ENVIR 
ONMENT  ENV3)  (Z  ROTATION  0.000000),  (TRANSLATION  t(4. 492600  4.492600  0;0 
00000  ))  )  ((TYPE  OBJECT)  (NMffl  MOrVKABLBJVISBJJAMJL)  (APPLICATION  APP3 
)  (ENVIRONMENT  ENV3)  (Z_ROTATION  0.00000^)  (t^^SLATION  (5.792600  5.82 
7600  0.000000  ))  )  )'  (494) 

(Output: :s«}id)  ' (PLANNED  ((NAME  NONE)  (TYPE  MESSAGE)  (TO  nona)  (PROM  n 
one)  )  ((NAME  FOOD  (TYPE  BDILD__SETOP)  (XJROTATION  0.000000)  (YJROTATI 
ON  0.000000)  (Z  ROTATION  0.000000)  (TRANSLATION  (0.000000  0.000000  0.0 
00000  ))  (SETOPJIO  3)  (APPLICATION  APP3)  (ENVIRONMENT  ENV3)  (PART  OBJ3 
)  (PINISHED_PART  NONE)  (ANGLE  6.000000)  (SUBPLATEJ^EPTH  0.000000)  (POS 
ITION  X)  (MODE  MANUAL)  (METHOD  NONE)  (NC_PILENAME“788dh/usr2/baird/im 
x/hz/doc/ezaiBple/hz_macro_3")  (FIXTURES  (FIXED_VISE_JAW_1  PARALLEL_BAR 
_1  MOVEABLE_VISE_JAW_l  ))“”)  )'  (503) 
no  such  name  'none'  for  Send 


>  (read  ((type  file){name  "tool.dc.4"))) 

(Holding)  Error  in  Setup: :AttrMethod:  bad  method  NONE  received 
(Output: ’.send)  '(GET  ((NAMEG9)  (TYPE  MESSAGE)  (TO  mz)  (FROM  hz)  )  ( (T 
YPE  BREP)  (APPLICATION  APP4)  (ENVIRONMENT  ENV4)  (OBJECT  OBJ4)  (NAME  OB 
J4)  )  )'  (131)  •  ■  • 

Fizture  plan  with  toeclazqis  or  a  vise  nuiy  exist 


***  Pin  Location  in  part  coord.  *** 


PIN  X  Y 

1  0.457  -0,250 

2  1.871  -0.250 

3  -0.250  0.457 


Mas.  Height 
0.240 
0.240 
0.240 


Total  no.  of  Clasp  Ranges  »  3 


***  CLAMP  RANGES  *** 


xl 

yi 

zl 

z2 

y2 

1 

0.500 

0.000 

0.170 

2.000 

0.000 

2 

0.000 

0.000 

0.340 

O.SOO 

0.000 

3 

2.000 

0.000 

0.340 

2.500 

0.000 

z2  length 
0.170  1.500 

0.340  0.500 

0.340  0.500 


***  Fizture  with  toeclasps  on  a  sinejplate  (angle  «  30.000)  *** 

Nasae  Size  X  Y  Z 


pin 

13.935 

27,370 

O.QOO 

pin 

15.349 

27.370 

0.000 

pin 

13.228 

28.077 

0.000 

past 

13.478 

27.620 

0.000 
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clasp 

clasp 


14.278  27.620  0.170 

15.178  27.620  0.170 


(Output::: sand)  '  (COPY  ((NAME  GIO)  (TYPE  MESSAGE)  (TO  sue)  (PRCM  )  ( 
(T»E  OBJECT)  (NAME  I.bCATOR__l)  (APPLICATION  LIBR^)  (ENVIRONMENT  FIXE 
LS)  (TO  APPLICATION  APP4)  (TOJENVIRONWENT  ENV4)  y  ((TYPE  OBJECT)  (NAME 
LOCATOR  2)  (APPLICATION  LIBRARY)  (EN^RONMENT  PIXELS)  (TO__APPLICATION 
APP4);  (TOJENVIRONMENT  ENV4)  )  ((TYPE  OBJECT)  (NAME  LOCATOR__3)  (APPLIC 
ATION  LIBRARY)  (ENVIRONMENT  PIXELS)  (TO__APPLICATION  APP4)  (TO_ENVIRONM 
ENT  ENV4)  )  ( (TYPE  OBJECT)  (NAME  TOE_CLAMP^i)  (APPLICATION  LIBRARY)  (E 
NVIRONMENT  PIXELS)  (TO_APPLICATION  APP4)  (TOJENVIRONMENT  ENV4)  )  ( (TYP 
E  OBJECT)  (NAME  TOEjCLAMPJZ)  (APPLICATION  LIBRARY)  (ENVIRONMENT  PIXELS 
)  (TOJAPPLICATION  APP4)  (TOJENVIRONMENT  ENV4)  )  )'  (663) 

(Output:.: sand)  '  (TRANSFORM  ( (NAMlt^  Gil)  (TYPE  MESSAGE)  (TO  sue)  (PROM  hx 
)  )  ( (TYPE  OBJECT)  (NAME  LOCATOR_l)  (APPLICATION  APP4)  (ENVIRONMENT  EN 
V4)  (Z_ROTATION  0.000000)  (TRANSLATION  (13.334900  27.369801  0.000000  ) 

)  )  ( (TYPE  OBJECT)  (NAME  LOCATORJ2)  (APPLICATION  APP4)  (ENVIRONMaiT  EN 

V4)  (2JR.0TATI0N  0.000000)  (TRANSLATION  (15.349100  27.369801  0.000000  ) 

)  )  ( (TYPE  OBJECT)  (NAME  LOCATOR_3)  (APPLICATION  APP4)  (ENVIRONMENT  EN 
V4)  (Z__ROTATION  0.000000)  (TRANSLATION  (13’. 227800  28.076900  0.000000  ) 
.)  )  ( (TYPE  OBJECT)  (NAME  TOEjCLAMP_l)  (APPLICATION  APP4)  (ENVIRONMENT 
ENV4)  (2_ROTATiON  0.000000)  TtRANSLATION  (14.277800  27.619801  0.170000 
) )  )  ( (TYPE  OBJECT)  (NAME  T0EJ:LAMPJ2)  (APPLICATION  APP4)  (ENVIRONMEN 
T  ENV4)  (2JR0TATI0N  0.000000)  TtRANSLATION  (15.177800  27.619801  0.1700 
00  ))  )  )'  (763) 

(Output: : sand)  '(PLANNED  ((NAME  NONE)  (TYPE  MESSAGE)  (TO  none)  (PROM  n 
one)  )  ((NAME  P004)  (TYPE  BUIIJJSBTUP)  (X_ROTAT10N  0.000000)  (YJROTATI 
ON  O.pOOOOO)  (ZJftOTATION  180.000*000)  (Tl^SLATION  (0.000000  O.O'OOOOO  0 
.000000  ))  (SE3:ip__NO.  4)  (APPLICATION  APP4)  (ENVIRONMENT  ENV4)  (PART  OB 
J4)  (PINISHEDJPART  NOME)  (ANGLE  30.000000)  (SUBPLATE_DEPTH  0.000000)  ( 
POSITION  X)  (MODE  MANUAL)  (METHOD  NONE)  (NCJPILENAME  "/ssdh/uss2/bsird 
/iaw/hx/doc/axaBpla/hxjBacroj4")  (FIXTURES  (LOCATOR_l  L0CAT0R_2  LOCATO 
R__3  TOE_CLAMP_l  TOE_CLAMP_2  T)  )  ) '  ^508)  “ 

no  such  nasia  'none'  for  Send 


14.  Errors  and  Warnings 

If  the  holding  expert  cannot  plan  fixtures  for  the  setup,  it  will  return  a  NOTPLANNED  message 
to  the  originator  of  the  PLAN  request.  See  the  NOTPLANNED  verb  description  for  a  list 
attributes.  The  ERRORS  attribute  will  have  one  of  the  following  strings  (underlined): 

"No  fixture  element" 

This  means  that  the  main  fixture  planning  routine  could  not  create  a  plan.  One  frequent  cause  of 
this  is  that  the  part  is  too  small  or  too  big  for  the  current  fixture  geometry  compiled  into  holding 
expert. 

"No  macro  file  name" 

This  means  that  although  a  plan  was  created,  the  nc  file  name  containing  the  code  to  load  the 
fixtures  was  not  generated.  This  case  only  happens  when  there  is  an  internal  error  in  the  main 
fixture  plaiming  routine. 

"No  part  brep  firom  modeler" 
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This  means  that  the  GET  message  to  the  modeling  expert  returned  NOTGOTTEN.  This 
typically  happens  when  the  PART,  APPLICATION,  or  ENVIRONMENT  passed  in  from  the 
PLAN  verb  are  not  the  names  that  are  in  the  modeler. 

"Unable  to  copy  fixtures  to  model" 

This  means  that  after  creating  a  setup  plan  containing  a  list  of  fixtures,  the  COPY  message  (from 
the  holding  expert- to  the  modeler)  failed  to  copy  fixtures  from  the  fixture  library  to  the  current 
part  environment.  Typically  this  is  caused  by  not  loading  the  fixture  library  into  the  modeler,  or 
the  fixture  library  names  do  not  agree  with  the  holding  expert  names,  or  that  the  number  of 
fixtures  in  the  library  is  less  than  what  the  holding  expert  requested. 

"Unable  to  transform  fixtures  in  model" 

This  means  that  after  creating  a  setup  plan  containing  a  list  of  fixtures  and  copying  them  from 
the  library  to  the  current  part  environment,  the  TRANSFORM  message  (from  the  holding  expert 
to  tlie  modeler)  failed  to  transform  fixtures  in  the  current  part  environment.  This  has  the  same 
failures  as  the  previous  "Unable  to  copy  fixtures  to  model"  message  but  is  less  likely  to  appear 
because  the  copy  message  generates  the  error  first.  This  message  will  be  seen  if  the  modeler 
copy  command  silendy  fails,  but  the  transform  reports  NOTTRANSFORMED. 

Other  errors  and  warning  are  just  printed  on  the  terminal.  Since  the  other  expert  systems  will  not 
utilize  warnings,  they  are  printed  instead  of  being  included  in  a  return  message.  The  most 
common  causes  of  warnings  are  using  an  obsolete  attribute  or  omitting  an  attribute  (but  a 
reasonable  default  value  can  be  supplied.)  Other  errors  printed  out  instead  of  returning 
NOTPLANNED  ai’e  fatal.  These  arc  typically  from  leaving  out  an  attribute  that  no  reasonable 
default  can  be  supplied  for  (e.g.,  MINOR_NORlvIAL.)  Any  message  with  "new  TYPENAME 
failed"  is  a  fatal  error  in  memory  allocation  procedure  (e.g.,  malloc  out  of  memory.)  The  only 
option  at  this  point  is  to  "(quit)"  and  restart  the  program. 

Both  printed  errors  and  warnings  have  the  following  format: 

(Holding)  etype  in  prog:  srrstr 

where  ETYPE  is  "Error"  or  "Warning",  PROC  is  a  procedure  name  or  a  class::method  name  and 
ERRSTR  is  some  descriptive  string.  Note!  All  errors  are  printed  on  stdout,  not  stderr! 
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1.  Introduction 


1 

This  document  desaibes  a  library  of  C++  classes  that  supports  the  common  elements  of 
the  Cutting,  Holding,  Sensing,  and  Modeling  subsystems  of  the  Intelligent  Machining 
Workstation  (IMW),  and  how  to  construct  such  a  subsystem  based  on  this  library.^ 
Since  the  various  subsystems  that  have  been  developed  with  this  library  are  termed  "ex¬ 
perts",  e.g..  Cutting  Expert,  we  call  the  library  itself  the  Generic  Expert. 

This  document  is  necessarily  somewhat  technical,  since  it  is  intended  for  someone 
writing  a  computer  program  such  as  the  Cutting  Expert  in  the  C++  language.  It  presup¬ 
poses  an  imderstanding  of  C++.- 

2.  Purpose 

The  purpose  of  the  Generic  Expert  library  is  to  reduce  the  effort  required  to  produce  a 
subsystem  for  the  IMW'that  interfaces  properly  with  the  rest  of  the  system.  Since  com¬ 
munication  capabilities  are  required  by  all  subsystems,  they  are  provided  in  the  Generic 
Expert.  All  subsystems  are  also  expected  to  communicate  in  a  common  language.  Fea¬ 
ture  Exchange  Language  (FEL),  so  an  FEL  parser  and  FEL  sentence  generation  proce¬ 
dures  are  part  of  the  Generic  Expert.  A  simple  terminal  interface  is  also  provided. 

In  the  following  sections,  we  describe  the  various  user-accessible  C++  classes  in  the  Ge¬ 
neric  Expert  library  that  enable  the  user  to  take  advantage  of  these  common  capabilities. 
We  also  recommend  a  programming  style  that  will  enable  the  user  to  best  take  advan¬ 
tage  of  possible  future  enhancements. 

3.  C++ Task  Systf.m 

The  implementation  of  the  Generic  Expert  is  based  on  the  C++  Task  System,  which  is 
supplied  as  a  standard  library  v/ith  the  AT&T  C++  translator.  We  describe  only  the 
basic  features  in  this  section.^  Note:  we  use  the  version  of  the  Task  System  which  sup¬ 
ports  waiting  on  UNIX  SIGNALS,  as  desaibed  in  IShopiro  1987].  The  Generic  Expert  will 
not  work  with  the  old  version. 

3.1.  Tasks 

The  Task  System  defines  a  type  of  'lightweight  process"  in  the  guise  of  the  class  task. 
Constructors  of  classes  (directly)  derived  from  dass  task  can  share  the  CPU  under  the 
control  of  a  task  scheduler.  Each  such  task  can  be  suspended  and  later  resumed  with¬ 
out  disturbing  its  internal  state,  but  suspension  is  always  voluntary,  occurring  only 
when  a  task  chooses  to  wait  for  an  event  to  occur. 

Tasks  are  created  by  defining  a  dass  that  derives  directly  from  the  base  dass  task  and 
by  implementing  a  constructor  for  the  new  dass  that  does  the  work  that  the  nevy  task  is 
supposed  to  do.  The  only  serious  requirement  that  the  constructor  must  satisfy  is  that  it 
must  terminate  properly  by  invoking  the  function  resultis(O).  The  example  near  the 

1.  The  library  file  is  named  libshell.a.  The  system  also  requires  the  new  AT&T  C++  Task  System  that 
supports  software  interrupts  (i.e.,  signals). 

2.  See  [Stroustnip  1986]. 

3.  See  [Stroustnip  1987]  and  [Shopiro  1987]  for  detailed  descriptions  of  the  Task  System. 
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end  of  this  document  does  this  by  using  the  macro  TERMINATE  (defined  in  macros.h). 
3.2.  Queues 


The  Task  System  defines  a  type  of  first-in-first-out  queue  based  on  two  classes:  qtail 
and  qhead.  Tasks  can  communicate  through  such  a  queue.  One  task  "puts"  an  object 
to  an  instance  of  class  qtail,  while  another  task  waits  for  the  arrival  of  an  object  on  the 
corresponding  qhead.  The  action  of  waiting  causes  the  task  to  be  swapped  out  by  the 
task  scheduler;  ^e  arrival  of  a  object  on  the  qhead  causes  tasks  that  are  waiting  on  that 
qhead  to  be  put  on  the  run  chain. 

3.2.1.  Message  Queues 

Queues  are  used  extensively  within  the  Generic  Expert  for  intra-expert  communicafion 
between  the  multiple  tasks  that  make  up  a  program  built  from  the  Generic  Expert 
library.  These  queues  are  instances  of  two  classes,  MessageQHead  and  MessageQTail, 
that  are  derived  from  qhead  and  qtail.  These  classes  are  specialized  to  handle  only  ob¬ 
jects  of  type  Message. 

Class  MessageQTail  defines  only  two  functions: 

int  put  (Message*) 

MessageQHead*  head  () 

The  put  function  puts  a  message  on  a  queue;  this  action  can  cause  a  task  to  block  if  the 
queue  is  full.  The  head  function  returns  a  pointer  to  the  head  of  the  queue. 

Class  MessageQHead  defines  three  functions: 

Message*  get  () 

int  putback  (Message*) 

MessageQTJail*  tail  () 

The  get  function  retrieves  the  next  message  from  the  head  of  a  queue;  if  there  is  no  mes¬ 
sage,  the  task  will  block  until  a  message  arrives.  The  putback  function  returns  a  message 
to  the  head  of  a  queue.  The  tail  function  returns  a  pointer  to  the  tail  of  the  queue. 

3.22.  Creating  Queues  between  Tasks 

The  following  example  shows  how  to  connect  two  tasks  via  a  queue.  This  code  is  taken 
from  the  "central  control"  task  in  the  Generic  Expert;  this  is  how  the  Generic  Expert  sets 
up  queues  to  communicate  with  the  user's  Expert  task. 

/*  create  the  queue  I  will  read  from  */ 

MessageQHead*  myQHead  «  new  MessageQHead; 

MessageQTail*  myQTail  *  myQHead  ->  tail  (); 

/*  create  the  queue  he  will  read  from  */ 

MessageQHead*  aQHead  •»  new  MessageQHead; 

MessageQTail*  toExpert  -  aQHead  ->  tail  (); 

/*  create  the  task  */ 
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(void),  new  Expert  (argvO,  aQHead,  rayQTail)  ; 

Note  that  only  one  end  of  a  queue  (here  a  MessageQHead)  is  actually  created  using  neu). 
You  get  a  pointer  to  the  other  end  by  invoking  the  appropriate  tail  or  head  function  (in 
our  case,  tail).  The  task  Expert,  defined  in  experth,  has  a  MessageQHead*  parameter, 
from  which  it  receives  its  messages,  and  a  MessageQTaii*  p^ameter,  to  which  it  puts 
messages  that  it  wanfe  to  send  to  the  "central  control"  task.  The  "central  control"  task 
sends  messages  to  Expert  by  putting  them  on  the  toExpert  MessageQTail. 

The  user's  Expert  tek  could  create  sub-tasks  of  its  own,  together  with  appropriate 
queues  to.communicate  with  them. 

4.  Class  Expert 

The  primary  effort  in  developing  a  program  based  on  the  Generic  Expert  is  the 
implementation  of  the  constructor  for  class  Expert,  as  declared  in  the  file  expert.h. 
What  this  means,  basically,  is  that  one  has  to  write  a  C++  subroutine  with  the  following 
procedure  declaration: 


Expert: : Expert  (char*  myName, 

MessageQHead*  readFrom, 

MessageQTail*  writeTo) 

This  subroutine  automatically  becomes  a  task**  within  the  final  program.  It  communi¬ 
cates  with  other  tasks  and  subsystems  via  two  message  queues,  which  are  capable  of 
transmitting  Sentences,  described  below.  Incoming  messages  are  retrieved  from  the 
head  of  the  "readFrom"  queue;  outgoing  messages  are  placed  on  the  tail  of  the  "write¬ 
To"  queue. 

To  wait  for  the  arrival  of  a  message,  use  the  member  function  get: 

/*  Messages  are  described  in  the  next  section  */ 

Message*  request; 

request  =  readFrom  ->  get(); 

This  puts  your  task  to  sleep  until  a  message  is  available  from  the  "readFrom"  queue.  To 
send  a  message,  use  the  member  function  put: 

/*  Assume  that  aSentence  is  an  instance  of  class  Sentence, 
described  below.  */ 

Message*  reply  «  new  Message  (OUTPUT,  aSentence) ; 
writeTo  ->  put  (reply) ; 

This  CTeates  a  new  message  with  a  Sentence  tiiat  is  destined  for  a  subsystem  on  the 
network  and  then  puts  it  into  a  queue  where  it  can  be  picked  up  by  another  task,  which 
will  handle  the  details  of  the  transmission.  Sending  a  message  does  not  suspend  a  task. 

A  prototype  implementation  of  Expert::Expert  is  provided  in  the  file  expert.c.  The 
developer  should  replace  the  program  block  imder  case  INPUT  with  his  own  code.  See 
the  Example  section  later  in  the  document.  One  of  the  main  features  of  this  prototype  is 
that  it  gets  aU  input  in  one  place.  For  this  to  work  effectively,  the  code  you  add  should 

4.  See  [Stroustoup  1987]. 
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be  designed  to  do  only  a  small  amount  of  work  each  time  this  task  becomes  active.^ 

5.  Class  Message 

Instances  of  this  class  represent  messages  that  are  passed  between  tasks  wj.thin  a  single 
subsystem;  so  users  do  not  have  to  know  much  about  them,  except  for  how  to  retrieve 
the  contents — presumably  a  Sentence — ^from  an  incoming  message  and  how  to  package 
a  Sentence  into  a  message  for  transmission  to  another  subsystem. 

Qass  Message  contains  a  public  data  field  called  mContents  which  contains  a  pointer  to 
the  contents  of  the  message.  No  information  about  the  size  of  the  data  is  maintained  by 
the  Message  class.  Here  is  how  a  sentence  can  be  extracted  from  a  message. 

/*  get  a  message  and  access  its  contents  as  a  Sentence  */ 

Message*  recjuest; 

request  =  readFrom  ->  get(); 

Sentence*  theSentence  =  (Sentence*) (request  ->  mContents) ; 

Packaging  a  sentence  as  a  message  for  transmission  to  the  Output  task  for  delivery  to 
another  subsystem  is  simple  using  the  constructor  for  class  Message: 

Message*  reply  =  new  Message  (OUTPUT,  aSentence) ; 
writeTo  ->  put  (reply) ; 

Messages  can  also  be  used  to  put  an  error  message  on  the  standard  output  stream  as  fol¬ 
lows: 


Message*  error  =  new  Message  (ERROR,  "Naughty,  naughty!"); 
writeTo  ->  put  (error) ; 


6.  Class  Sentence 

Instances  of  class  Sentence  represent  PEL  messages.  Member  functions  provide  access 
to  significant  components  of  a  message  and  allow  the  construction  of  new  messages. 
Currently  supported  fimctions  include: 

Sentence  () 

Sentence  (VERB_ENUM  aVerb) 

The  constructor  takes  an  optional  VERB_ENUkd  as  an  argument.®  If  none  is 
supplied,  the  verb  will  default  to  VERB_NONE. 

Sentence*  append  (FeatureList*  fList) 

The  function  append  appends  a  FeatureList  to  a  Sentence.  The  argument  is  a 
pointer  to  the  FeatureList  to  be  appended.  A  pointer  to  the  new  Sentence  is 
returned. 

ADDR_ENUM  destination  0 

5.  We  do  not  describe  in  this  document  how  to  accomplish  this.  Future  documentation  on  the  to-be-de¬ 
veloped  inter-sub^stem  dialogue  mechanism  will  include  a  technique  based  on  the  rescheduling  of  a 
task. 

6.  Refer  to  the  file  verb.h  for  the  definition  of  VERB_ENUM. 
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The  function  destination  returns  as  an  ADDR_ENIJM  the  address  of  the  receiver 
of  the  message/  This  is  the  value  of  the  TO  attribute  within  the  feature  list  of 
type  MESSAGE. 

FeatureList*  featureListOf  (TYPE_E]SrUM  aType) 

The  function  featureListOf  searches  the  feature  lists  that  compose  a  Sentence  and 
returns  a  pointer  to  the  first  feature  list  whose  TYPE  attribute  has  the  value 
aType. 

Sentence*  insert  (FeatureList*  fList) 

The  function  insert  inserts  a  Featurelist  before  other  Featurelists  in  a  Sentence. 
The  argument  is  a  pointer  to  the  Featurelist  to  be  inserted.  A  pointer  to  the  new 
Sentence  is  returned. 

Sentence*  reply  (VERB_ENUM  aVerb) 

The  function  reply  creates  and  returns  a  pointer  to  a  new  Sentence  that  can  be 
used  as  a  reply  to  a  message.  It  will  contain  a  FeatureList  with  the  same  NAME 
and  TYPE  attributes  as  the  original  Sentence,  but  with  values  of  the  TO  and 
FROM  attributes  reversed.  The  argument  aVerb  specifies  the  value  of  the  verb 
for  the  new  message. 

Sentence*  setVerb  (VERB_ENIJM  aVerb) 

The  function  setVerb  makes  the  argument  aVerb  the  new  value  of  the  verb  of  the 
Sentence.  A  pointer  to  the  Sentence  is  returned. 

ADDR_ENUM  source  () 

The  function  source  returns  as  an  ADDR_ENUM  the  address  of  the  sender  of  the 
message.  This  is  the  value  of  the  FROM  attribute  within  the  feature  list  of  type 
MESSAGE. 

VERB_ENUM  vorb  () 

The  function  verb  returns  the  verb  of  the  Sentence  as  a  VERB_ENUM. 

The  intended  use  of  this  class  is  illustrated  by  the  following  example  of  how  to  create  a 
reply  to  a  message. 

{ 

/*  assume  that  aSentence  is  a  pointer  to  a  Sentence  */ 

/*  and  that  aVerb  is  appropriate  for  the  reply  to  aSentence  */ 
Sentence*  response  “  aSentence  ->  reply  (aVerb) ; 

/*  add  one  FeatureList  */ 

FeatureList*  fList  -  new  FeatureList; 

fList  ->  include  (ATTR_NAMB,  VT_SYMBOL,  aName) ; 

fList  ->  include  (ATTR_TYPE,  VT_TYPE,  TYPE_FIXTURE) ; 

response  ->  append  (fList) ; 

/*  send  the  response  */ 

/*  assume  that  writeTo  is  an  appropriate  MessageQTail 
pointer  */ 

7.  Refer  to  the  file  addr.h  for  the  definition  of  ADDR_ENUM. 
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Message*  m  =  new  Message  (OUTPUT,  response) ; 
writeTo  ->  put  (m) ; 

1 


7.  Class  Sentence  Iterator 

Instances  of  class  Sentencelterator  allow  one  to  step  through  the  feature  lists  of  a 
Sentence.  Each  call  to  the  member  function  nextO  returns  a  pointer  to  a  FeatureList.  A 
zero  is  returned  after  all  the  feature  lists  have  been  returned.  Currently  supported 
functions  include: 

Sentencelterator  (Sentence&  aSentence) 

The  constructor  takes  a  reference  to  a  Sentence  as  its  sole  argument. 

FeatureList^^  first  0 

The  function /frsf  resets  the  iterator  and  returns  a  pointer  to  the  first  FeatureList 
in  the  Sentence. 

FeatureList*  next  () 

The  function  next  returns  a  pointer  to  the  FeatureList  following  the  last  one 
returned  by  this  function,  or  to  the  first  FeatureList  in  the  Sentence  if  none  has 
been  returned  from  the  Sentencelterator  since  it  was  created.  A  zero  is  returned 
when  a  pointer  to  every  FeatureList  has  been  returned. 

This  class  is  provided  so  that  one  can  sequentially  process  all  the  feature  lists  in  a 
message  without  having  to  know  the  intemd  representation  of  messages.  The  intended 
use  is  illustrated  in  the  following  example: 

{ 

/*  assume  that  aSentence  is  a  pointer  to  a  Sentence  */ 

Sentencelterator  siter  (*aSentence) ; 

FeatureList*  fList; 

while  (fList  »  siter .next () )  ( 

/*  process  the  FeatureList  pointed  to  by  fList  */ 


) 

} 


8.  Class  Feature  List 

Instances  of  class  FeatureList  represent  the  list  of  attribute/value  pairs  that  are  the 
principal  components  of  FEL  messages.  Member  functions  provide  access  to  the  values 
of  the  pairs  and  allow  the  construction  of  new  lists  of  pairs.  Currently  supported 
functions  include: 

FeatureList  0 
FeatureList  (char*  aName) 
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The  constructor  takes  an  optional  char*  as  an  argument.  If  none  is  supplied,  the 
value  will  default  to  zero.  When  the  optional  name  is  supplied,  it  is  construed  as 
the  name  of  an  existing  FeatareList  and  no  attribute/value  pairs  should  be 
ada^d  to  this  new  FeatureUst. 

FeatureList*  append  (AttributeValuePair*  avPair) 

The  function  append  appends  an  AttributeValuePair  to  a  FeatureList.  The 
argument  is  a  pointer  to  the  AttributeValuePair  to  be  appended.  A  pointer  to  the 
FeatureList  is  returned. 

void  include  (ATTR_ENIJM,  VT_ENUM,  int,  int) 
void  include  (ATTR_ENUM,  VT_ENUM,  long,  int) 
void  include  (ATTR_ENUM,  VT_ENUM,  float,  int) 
void  include  (ATTR_ENIJM,  VT_ENUM,  double,  int) 
void  include  (ATTR_ENIJM,  VT_ENUM,  char*) 
void  include  (ATTR_ENUM,  VT_ENUM,  List*) 
void  include  (ATTR_ENUM,  VT_ENUM,  char**) 
void  include  (ATTR_ENUM,  VT_ENUM,  VECTTOR) 

The  include  functions  add  attribute/ value  pairs  to  the  beginning  of  a  FeatureList. 
The  attribute  is  given  in  the  first  argument.  The  type  of  value  is  given  in 
argument  two  and  the  actual  value  in  argument  three.  An  optional  fourth 
argument  specifies  the  units  (as  a  UNTT^ENUM)  of  the  value. 

FeatureList*  insert  (AttributeValuePair*  avPair) 

The  function  insert  inserts  an  AttributeValuePair  before  other 
AttributeValuePairs  in  a  FeatureList.  The  argument  is  a  pointer  to  the 
AttributeValuePair  to  be  inserted.  A  pointer  to  the  FeatureList  is  returned. 

TYPE_ENUMtypeOfO 

The  fimction  fypeO/ returns  the  value  of  the  pair  whose  attribute  is  ATTR_TYPE. 

ValueType*  valueOf Attribute  (ATrR_ENUM) 

ValueType*  valueOf Attribute  (char*) 

The  valueOfAttribute  functions  return  a  pointer  to  the  value  (an  instance  of  class 
ValueType)  of  the  attribute  specified  by  their  arguments.  The  argument  is  either 
an  ATTO_ENUM  (the  usual  case)  or  the  name  of  an  attribute. 

The  intended  use  of  this  class  is  illustrated  in  the  following  two  examples.  The  first 
shows  how  to  aeatc-  a  new  list  of  attribute/ value  pairs.  The  second  shows  how  to 
retrieve  values  from  such  a  list. 

{ 

/*  Allocate  a  new  FeatureList.  */ 

FeatureList*  fList  ■  new  FeatureList; 

/*  Include  the  pair  whose  attribute  is  ATTR_NAME 
and  whose  value  is  the  symbol  aName.  */ 
fList  ->  include  (ATTR_NAME,  VT_SYMBOL,  aName); 

/*  Include  the  pair  whose  attribute  is  ATTR_TYPE 
and  whose  value  is  the  type  TyPE_FIXIURE .  */ 
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fList  ->  include  (ATTR_TypE,  Va‘_TYPE,  TYPE  FIXTURE)  ; 


/*  Assume  that  fList  is  the  FeatureList  created 
in  the  above  example.  One  can  retrieve  its 
values  as  follows.  */ 

ValueType*  vType; 
char*  aSymbol; 

TyPE_ENUM  aType; 

vType  =  valueOfAttribute  (ATTR_NAME) ; 
aSymbol  =  (char*)  vType; 

vType  =  valueOfAttribute  tATTR_TYPE) ; 
aType  =  (int)  vType; 


9,  Class  Feature  List  Iterator 

Instances  of  class  Featurelisrlterator  allow  one  to  step  through  the  list  of  pairs  of  a 
FeatureList.  Each  call  to  the  member  function  nextO  returns  a  pointer  to  an 
AttributeValuePair.  A  zero  is  returned  after  all  the  pairs  have  been  returned.  Currently 
supported  functions  include: 

FeatureListIterator  (FeatureList&) 

The  constructor  takes  a  reference  to  a  FeatureList  as  its  sole  argument. 
AttributeValuePair*  first  0 

The  function  first  resets  the  iterator  and  returns  a  pointer  to  the  first 
AttributeValuePair  in  the  FeatureList. 

AttributeValuePair*  next  0 

The  function  next  returns  a  pointer  to  the  AttributeValuePair  following  the  last 
one  returned  by  this  function,  or  to  the  first  AttributeValuePair  in  the  FeatureList 
if  none  has  been  returned  from  the  FeatureListIterator  since  it  was  created.  A 
zero  is  returned  when  a  pointer  to  every  AttributeValuePair  has  been  returned. 

This  dass  is  provided  so  that  one  can  sequentially  process  all  file  pairs  in  a  FeatureList 
without  having  to  know  the  internal  representation  of  feature  lists.  The  intended  use  is 
illustrated  in  the  following  example: 

{ 

/*  assume  that  aFeatureList  points  to  a  FeatureList  */ 

FeatureListIterator  fiter  (*aFeatureList) ; 

AttributeValuePair*  avPair; 

while  (avPair  >=  fiter. next  () )  { 

/*  process  the  pair  pointed  to  by  avPair  */ 
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} 

} 


10.  Qass  Value  Type 

The  class  ValueType  is  the  base  class  for  a  set  of  derived  classes  that  represent  the 
various  primitive  types  of  values  that  may  appear  in  the  attribute/value  pairs  of 
messages.  These  include  addresses,  dimensioned  numbers,  integers,  material 
identi&rs,  real  numbers,  strings,  symbols,  type  identifiers,  and  lists  of  other  types  of 
values. 

The  two  most  important  things  that  can  be  done  with  these  classes  is  to  create  instances 
of  them  and  to  extract  their  underlying  values.  The  constructors  and  coercion  operators 
for  these  classes  are  documented  below. 

10.1.  Qass  Address 

This  class  represents  addresses  of  IMW  subsystems,  such  as  PL  (planner),  CX  (cutting  ex¬ 
pert),  HX  (holding  expert),  MX  (modeler),  etc.  If  you  are  generating  a  reply  to  a  sentence, 
you  do  not  care  where  it  came  from,  and  just  want  the  reply  to  go  back  to  the  sender, 
the  reply  function  in  class  Sentence  takes  care  of  creating  the  return  address. 

Address  (ADDR_ENUM) 
int  operator  int  0 

Instances  of  this  class  may  be  coerced  to  an  int,  which  will,  in  fact,  be  an 
ADDR_ENUM.^  Some  programs  will  not  care  where  messages  come  from,  so 
long  as  they  are  meaningful  messages  in  context. 

10.2.  Qass  Dimension 

This  class  represents  dimensioned  numbers. 

Dimension  (int,  UNrr_ENUM) 

Dimension  (long,  UNHIENUM) 

Dimension  (float,  LJNrr_ENUM) 

Dimension  (double,  UNIT_ENUM) 
int  operator  int  0 
long  operator  long  0 
double  operator  double  () 

The  constructors  take  a  numeric  first  argument  of  one  of  four  types:  int,  long, 
float,  or  double.  The  second  argument  specifies  the  units.  Instances  of  this  class 
may  be  coerced  to  an  int,  whose  value  will  be  the  dimension  part  of  the 
dimensioned  number  (of  type  UNIT_ENUM).^  They  may  also  be  coerced  to 
either  a  long  or  a  double,  whose  value  will  be  the  numeric  part  of  the 
dimensioned  number. 


8.  Refer  to  the  file  addr.h  for  the  definition  of  ADDR_ENUM. 

9.  Refer  to  the  file  iinit.h  for  the  definition  of  UNrr_ENUM. 
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Integer  (int) 

Meger  (long) 
long  operator  long  0 

Hie  constructor  takes  either  an  int  or  a  long  as  argument;  internally  the  value  is 
represented  as  a  long.  Instances  of  the  dass  may  be  coerced  to  a  long. 

10.4.  Qass  Material 

This  class  represents  types  of  materials,  e.g.,  aluminum,  steel,  etc. 

Material  (MAT_ENUM) 
int  operator  int  0 

The  constructor  takes  as  argument  a  value  of  the  enumerated  type  MAT_ENIJM. 
Instances  of  this  class  may  be  coerced  to  an  int,  which  will,  in  fact,  be  a  value  of 
type  MAT_E^^^UM.^o 

10.5.  Qass  Real 

This  dass  represents  real  numbers. 

Real  (float) 

Real  Wouble) 

double  operator  double  () 

The  constructor  takes  either  a  float  or  a  double  as  argument;  internally  the  value 
is  stored  as  a  double.  Instances  of  this  dass  may  be  coerced  to  a  double. 

10.6.  Qass  String 

This  dass  represents  character  strings. 

String  U*  dynamically  allocated  V  char*) 
char*  operator  char*  0 

The  constructor  takes  a  null  terminated  dynamically  allocated  C  string  as 
argument.  Instances  of  this  class  may  be  coerced  to  a  C  string. 

10.7.  Qass  Symbol 

This  dass  represents  names  of  various  things. 

Symbol  (/*  dynamically  allocated  */  char*) 
char*  operator  char*  0 


10.  Refer  to  the  file  math  for  the  definition  of  MAT_ENUM. 
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The  constructor  takes  a  null  terminated  C  string  as  argument.  Instances  of  this 
class  may  be  coerced  to  a  C  string. 

10.8.  Class  Type 

This  class  represents  types  of  feature  lists. 

Type  (TYPE_ENUM) 
int  operator  int  0 

Instances  of  this  class  may  be  coerced  to  an  int,  whose  value  will  be  a  feature  list 
type  (of  type  TYPE_ENUM).^^ 

10.9.  QassList 

This  class  represents  a  list  of  values. 

ListO 

The  constructor  simply  aeates  a  new  empty  list. 

List*  append  (ValueType*  vType) 

List*  insert  (ValueT)^e*  vType) 

The  member  functions  append  and  insert,  respectively,  add  items  to  the  tail  and 
head  of  the  list. 

int  length  0 

The  member  function  length  returns  the  number  of  items  in  the  list.  The  user 
could  determine  this  information  using  a  Listiterator,  but  length  is  much  more 
efficient  and  convenient. 

VECTOR  operator  VECTORQ 
List*  VectorToList  (VECTOR) 

Lists  of  three  real  numbers  are  commonly  used  to  represent  vectors.  The  geomet¬ 
ric  modeler  used  by  the  MW  represents  vectors  as  a  struct  with  three  fields  rep¬ 
resenting  real  numbers  (x,  y,  and  z).  The  coercion  operator  VECTORQ  converts  a 
List  of  three  numbers  into  this  structure  representation.  The  fimction 
VectorToList  aeates  a  List  with  three  real  numbers  from  its  VECTOR  parameter. 

10.10.  Qass  Listiterator 

This  class  allows  one  to  step  sequentially  through  the  values  of  a  List. 

Listiterator  (List&  aList) 

ValueType*  first  () 

ValueType*  next  0 


11.  Refer  to  the  file  type.h  for  the  definition  of  TYPE_ENUM. 
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The  constructor  takes  a  reference  to  a  List  as  its  sole  argument.  The  function  first 
resets  the  iterator  and  returns  a  pointer  to  the  first  ValueType  in  the  List.  The 
function  next  returns  a  pointer  to  the  ValueType  following  the  last  one  returned 
by  this  function,  or  to  the  first  ValueType  in  Ae  List  if  none  has  been  returned 
from  the  Listiterator  since  it  was  created.  A  zero  is  returned  when  a  pointer  to 
every  ValueType  has  been  returned. 

11.  Example 

The  following  code  is  a  template  from  which  an  IMW  subsystem  can  be  developed.  The 
implementor  is  primarily  responsible  for  replacing  the  comment 

/*  USER  CODE  GOES  HERE  */ 

imder  "case  input"  with  whatever  code  segment  is  required  to  implement  the  sub¬ 
system.  This  will  probably  be  little  more  than  a  procedure  invocation.  If  there  is  one¬ 
time  initialization  to  be  done,  it  should  be  placed  tefore  the  BEGIN_TASK  macro. 

The  macros  BEGIN_TASK,  END_TASK,  EXIT_TASK,  and  TERMINATE  are  defined  in  mac- 
ros.h.  BEGIN_TASK  and  END_TASK  aeate  an  indefinitely  long  loop  that  gets  and  process¬ 
es  the  next  message  sent  to  this  task.  EXTTJTASK  causes  the  loop  to  terminate,  and 
terminate  terminates  the  task.  Aside  from  knowing  the  general  structure  imposed  by 
these  macros,  the  user  need  not  worry  about  them. 

#include  <inacros.h> 

#include  <parser.h> 

♦include  "expert. h" 

Expert: : Expert  <  char*  myName, 

MessageQHead*  readFrom, 

MesaageQTail*  writeTo  ) 

:  /*  task  */ (myName,  DEDICATED,  SIZE) 

( 

Message*  request; 

/*  USER  INITIALIZATION  GOES  HERE  */ 

BEGIN_TASK; 

request  =  readFrom  ->  get{); 

switch  (request  ->  mOperation)  { 
case  INPUT: 

{ 

/*  USER  CODE  GOES  HERE  */ 

) 

break; 
case  QUIT: 

EXIT_TASK; 
default : 

{ 

Message*  error  «•  new  Message  (ERROR, 

"(Expert)  Illegal  operation"); 
writeTo  ->  put  (error) ; 

1 
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break; 

1 

delete  request; 

END_TASK; 

TERMINATE; 

} 

If  the  subsystem  being  implemented  can  perform  its  function  without  intermediate 
commimication  with  other  subsystems,  then  it  can  be  implemented  as  a  function  that 
takes  a  Sentence  as  input  and  returns  a  Sentence  as  output. 


Sentence*  job  =  (Sentence*) (request  ->  mContents) ; 

Sentence*  reply  =  SintpleServerSubsystem  (job); 
writeTo  ->  put  (reply) ; 

In  most  cases  this  is  not  feasible  and  the  user's  code  must  be  designed  to  deal  with  mul¬ 
tiple  messages  per  job. 

12.  Makefile 

The  following  is  a  simple  makefile  for  CTeating  a  program  based  on  expert.c  and  the  Ge¬ 
neric  Expert  library. 

■#  INC  =  <the  directory  containing  macros. h  and  parser. h> 

#  LIB  =»  <the  directory  containing  libtask.a  and  libshell.a> 

CC  =  CC 

CFLAGS  =  “DPRIMITIVE  -C  -g  -I.  -1$ (INC) 

LIBTASK  =  $ (LIB) /libtask.a 
LIBSHELL  =  $ (LIB) /libshell.a 
MATHLIB  =  -Im 

LIBS  =  $ (LIBSHELL)  $ (LIBTASK)  $ (MATHLIB) 

OBJECTS  =  expert.o 


.c.o: 

$(CC)  $ (CFLAGS)  $*.c 
ex:  $ (OBJECTS) 

$(CC)  -f 68881  $ (OBJECTS)  $ (LIBS)  -0  ex 
expert.o:  expert. h  $ (INC) /macros. h  $ (INC) /parser. h 


13.  Release  Notes 

The  following  files  are  needed  to  use  the  generic  application  shell: 

libtask.a  C++  Task  library  (you  must  have  the  version  that  supports 
software  interrupts,  i.e.,  signals) 
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libshell.a  Generic  application  library  file. 

expert.c  A  template  for  the  implementation  of  the  constructor  for 
class  Bcpert. 

expert.h  Header  file  with  ^e  declaration  of  class  Expert. 


14.  Limitations 

There  is  a  limit  on  the  total  size  of  local  variables  associated  with  the  constructor  of  a 
task  such  as  Expert.  The  task  system  default  limit  is  defined  in  task.h  as  750. 
Applications  which  use  lots  of  stack  space  can  raise  this  limit  at  task  creation  time.  This 
is  the  function  of  the  SIZE  parameter  that  appears  in  the  line 

:  I*  task  */  (myName,  DEDICATED,  SIZE) 

at  the  beginning  of  the  constructor  for  class  Expert  (see  the  Example  section).  SIZE  is 
defined  in  expert.h. 
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Not  all  of  the  IMW  subsystems  run  under  the  Sun  UNIX  Operating  System.  The 
Planner,  Plan  Manager,  and  Human  Interface  are  Lisp-based  and  run  on  the  TI 
Explorer.  As  a  consequence,  a  Lisp-based  generic  expert  shell  is  provided  for  these 
subsystems. 

This  document  is  aimed  at  the  developer^  of  a  Lisp-based  IMW  .:ubsystem.  Since, 
communication  between  experts  takes  the  form  of  PEL  sentences,  explanations  and 
descriptions  are  provided  for  functions  that  ease  the  creation  and  modification  of  PEL 
sentences.  Lisp  forms  are  also  described  that  deal  with  dialogues,  a  higher  level 
grouping  of  sentences. 

At  the  end  of  this  section,  the  reader  will  find  a  glossary  of  functions  available  to 
the  writer  of  a  Lisp-based  expert.  This  glossary  contains  some  functions  that  were  not 
mentioned  in  prior  sections  of  the  text. 


1.  Dialogues  on  the  Lisp-based  Version  of  the  Generic  Expert 

Typically,  an  expert  exists  to  perform  some  service  requested  by  another  expert 
and,  for  every  request  received,  a  response  must  be  generated  and  returned.  Since  the 
lingua  franca  of  the  IMW  is  PEL,  both  the  request  and  the  response  are  in  the  form  of 
PEL  sentences.  A  dialogue  is  simply  the  exchange  of  PEL  sentences  that  occurs  due  to 
one  expert  making  a  request  of  another.  Por  our  purposes,  dialogues  will  be  viewed  as 
coming  in  two  versions:  simple  and  complex. 


1.1.  Simple  Dialogues 

A  simple  dialogue  is  defined  as  one  in  which  no  other  experts  must  be  contacted  in 
order  to  complete  the  dialogue.  That  is,  if  expert  A  makes  a  request  of  expert  B,  B  does 
not  need  to  initiate  a  dialogue  with  any  other  expert  in  order  to  generate  a  response  for 
A  (see  Pigure  1). 


1.  In  this  section,  the  writer  of  a  Lisp-based  expert  is  referred  to  as  a  sub^stem  integrator,  or  simply, 
an  integrator. 
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1.2.  Complex  Dialogues 

However,  the  system  architecture  of  the  Intelligent  Machining  Workstation  dictates 
that  an  expert  also  be  able  to  conduct  complex  dialogues.  In  other  words,  due  to  the 
specialization  of  the  experts  it  is  virtually  a  requirement  that  an  expert  be  able  to 
interact  with  other  experts  while  performing  a  service  triggered  by  an  FEL  sentence.  A 
complex  dialogue  will  be  defined  as  one  that  involves  separate,  independent  dialogues 
with  other  experts  in  order  to  generate  an  answer  for  the  expert  that  initiated  the 
original  dialogue. 

For  example,  the  Human  Interface  may  request  that  the  Planner  formulate  a  plan 
for  a  part.  During  the  process  of  planning,  the  Planner  determines  that  some 
information  is  required  from  the  Holding  Expert.  The  Planner  needs  to  be  able  to 
acquire  the  information  from  the  Holding  Expert  and  then  continue  the  planning 
process.  Finally,  when  the  planning  process  is  complete,  the  result,  in  the  form  of  an 
FEL  sentence,  •s^l  be  returned  to  the  Human  Interface.  What  has  transpired  is  two 
separate  dialogues.  A  dialogue  between  the  Human  Interface  and  the  Planner,  and  a 
dialogue  between  the  Planner  and  the  Holding  Expert.  The  first  dialogue,  which  was 
complex,  was  initiated  by  the  Human  Interface  and  involved  the  Planner.  The  second 
dialogue  was  originated  by  the  Planner  and  involved  the  Holding  Expert.  This 
dialogue  was  a  simple  dialogue  (see  Figure  2). 
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Figtire  2  Example  of  a  Complex  Dialogue 


1.2.1.  Fimctions  to  Facilitate  Complex  Dialogues 

The  latest  version  of  the  Lisp-based  generic  expert  provides  three  functions  that 
facilitate  complex  dialogues: 

(a)  spawn-r.eqilest, 

conditional-suspend,  and 
(c)  create-Qtest. 


I.2.I.I.  Spawn-Request 

While  an  expert  is  servicing  one  request,  it  is  not  at  all  unusual  to  need  some 
additional  information  or  a  service  performed  by  an  other  expert.  Spawn-request  is  the 
mechanism  provided  to  initiate  a  new  dialogue.  It  requires  four  arguments.  The  first 
argument  is  the  sentence  that  will  initiate  the  new  dialogue.  It  will  be  sent  to  the 
specified  expert.  This  sentence  requires  a  unique  name,  since,  it  is  through  the  sentence 
name  that  the  generic  expert  shell  is  able  to  direct  incoming  sentences  to  their 
appropriate  destinations. 

If  the  expert  specific  code  uses  the  function  bound  to  the  spawn  slot  of  an  object  of 
type  sentence,  then  the  integrator  need  not  worry  about  aeating  a  new  sentence  name. 
For  example,  if  FEL-sentence  is  such  an  object,  then  evaluation  by  the  Planner  of  the 
form: 


(funcall  (sentence- spawn  FEL-sentence)  : offer) 

returns  two  values  (a)  an  object  of  type  sentence,  and  G))  the  name  of  the  sentence.  The 
FEL  form  of  the  returned  sentence  is: 
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(offer  ( (name  unique-symbol)  (type  message)  (from  pi) ) ) 

Remember  the  name  of  this  new  sentence  is  a  unique  symbol. 

The  second  argument  to  spawn-request  is  the  function  used  to  queue  sentences  for 
output.  This  function  is  available  to  the  subsystem  integrator  as  the  first  argument 
passed  to  the  expert's  initial  function. 

Typically,  a  spawned  dialogue  will  generate  a  result.  The  third  argument  to  spawn- 
request  is  the  disposition  of  this  result.  Currently,  the  third  argument  may  be  one  of  two 
S5unbols,  either  .return-result  or  -.independent. 

A  disposition  of  return-result  signifies  that  the  originating  dialogue  expects  to  have 
access  to  the  final  result,  which  should  be  an  PEL  sentence.  In  order  to  gain  access  to 
this  PEL  sentence,  the  spawned  dialogue  should  ensure  that,  upon  termination,  this 
sentence  is  the  value  returned. 

The  symbol,  -.independent,  denotes  that  the  spawned  dialogue  may  proceed 
independently  of  the  spawner.  In  other  words,  the  spawned  dialogue  does  not  in  any 
way  need  to  concern  itself  with  returning  a  value  to  its  parent,  the  originating  dialogue. 

The  fourth  and  final  argument  to  spawn-request  is  the  function  that  will  handle  the 
spawned  dialogue.  The  first  argument  will  initiate  a  dialogue  with  another  expert,  say 
the  Holding  Expert.  When  the  Holding  Expert  responds  there  must  be  a  function 
provided  to  ded  with  the  respon£  i.  It  may  simply  accept  the  response,  or  engage  in  a 
protracted  negotiation  with  the  Holding  Expert.  The  point  is  that  whatever  occurs  is 
determined  by  the  provided  function.  This  function  should  be  written  to  accept  the 
same  arguments  as  the  initial  function.  Por  example,  a  function  that  would  just  accept 
the  response  rehimed  by  the  Holding  Expert  could  be  written  as  follows: 

(defun  handle-hx  (  enQ-outgoing 

Qstatus-incoming 
deQ-incoming 
conditional-suspend  ) 

"Handle  the  dialogue  with  the  Holding  Expert." 

(declare 

(ignore  enQ-outgoing) 

(ignore  Qstatus-incoming) 

(ignore  conditional-suspend) ) 

(let  (  (s  (funcall  deQ-incoming) )  ) 

(declare 

(type  sentence  s) ) 

(values  s) ) ) 


I.2.I.2.  Conditional-Suspend 
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Once  a  dialogue  has  been  spawned  the  originator  may  continue  processing.  Of 
course,  if  the  disposition  gi .  ..n  to  spawn-request  was  nreturn-result,  there  will  come  a  time 
when  the  response  from  the  spawned  dialogue  is  required  for  further  processing. 
However,  the  originator  has  no  way  of  knowing  the  state  of  the  spawned  dialogue. 
Therefore,  the  originating  dialogue  needs  a  way  of  suspending  operation  and  waiting 
for  the  result  from  the  spawned  dialogue.  This  functionality  is  provided  by  conditional- 
suspend,  which  is  available  to  the  subsystem  integrator  as  the  fourth  argument  passed  to 
the  expert's  initial  function,  conditional-suspend  ^qs  two  aig[iments.  The  first  is  a  test. 
When  it  evaluates  to  non-nil,  the  second  argument,  a  function,  is  executed. 

The  test  function  may  be  supplied  by  create-Qtest,  which  is  described  in  section 
I.2.I.3. 

conditional-suspend's  second  argument  should  dequeue  the  returned  result  from  the 
expert's  incoming  queue  and  continue  processing.  It  should  be  noted  that  this  function 
is  not  passed  any  arguments  when  it  is  finally  called.  Consequently,  the  integrator 
should  make  sure  that  the  fimction  has  access  to  whatever  local  variables  or  functions  it 
may  need.  For  example,  if  continue  is  the  function  to  be  called,  and  it  expects  ail  of  the 
arguments  that  are  passed  into  the  initial  function,  then: 

#' (lambda  ()  (continue  enQ-outgoing 

Qstatus-incoming 
deQ- incoming 
conditional-suspend) ) 

would  be  the  second  argument  passed  to  conditional-suspend. 

There  is  a  source  of  possible  confusion  that  needs  to  be  clarified,  conditional-suspend 
does  NOT  suspend  processing  of  the  function  that  calls  it.  That  is,  if  other  Lisp  forms 
follow  this  call,  they  are  executed  immediately  following  evaluation  of  the  conditional- 
suspend  form.  What  is  being  suspended  is  execution  of  frie  form  that  is  passed  as  a 
second  argument  to  conditional-suspend. 


I.2.I.3.  Create-Qtest 

As  mentioned  above,  conditional-suspend  requires  a  form  that  provides  a  test  to 
determine  when  to  execute  its  second  argument.  If  a  dialogue  is  waiting  for  a  spawned 
dialogue  to  complete,  then  a  test  is  needed  to  make  such  a  determination.  create-Qtest 
will  return  just  such  a  test.  That  is,  create-Qtest  creates  and  returns  a  function  that  will 
query  a  queue  and  return  a  boolean  value  depending  on  the  outcome. 

create-Qtesfs  primary  purpose  is  to  be  used  in  conjunction  with  conditional-suspend. 
As  a  consequence,  the  following  description  is  based  upon  that  usage.  create-Qtest 
expects  two  arguments.  The  first  argument  is  a  function  that  queries  a  queue.  Of  the 
arguments  passed  to  the  initial  fimction,  this  is  the  second  argument.  create-Qtest' s 
second  argument  is  a  list  of  dialogue  names  (possibly  just  one).  The  names  should  be 
the  ones  for  which  the  originating  dialogue  wants  to  wait. 
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1.2.2.  Example 

Following  is  an  example  that  outlines  the  use  of  the  above  functions.  Scenario:  this 
is  a  piece  of  code  from  PL,  the  initial  function  of  the  Planner.  An  incoming  sentence  is 
dequeued.  Some  processing  is  performed.  It  is  determined  that  a  dialogue  must  be 
initiated  with  the  Holding  Expert.  The  request  sentence  is  created.  Once  the  request 
sentence  is  properly  initidized,  a  new  dialogue  is  spawned.  At  this  point  the  Planner 
may  continue  processing.  When  the  time  comes  to  retrieve  the  response  from  the 
Holding  Expert,  a  call  to  conditional-suspend  is  made. 

(defun  pi  (  enQ-outgoing 

Qstatus-incoming 
deQ-incoming 
conditional-suspend  ) 

(let  (  (FEL-sentence  (funcall  deQ-incoming) )  ) 

(declare 

(type  sentence  FEL-sentence) ) 
some  processing 

(multiple-value-bind  (request-sentence  dialog-name) 
(funcall  (sentence-spawn  FEL-sentence)  : offer) 
(declare 

(type  sentence  request-sentence) 

(type  keyword  dialog-name) ) 

(setf  (sentence-to  request-sentence)  :hx) 

some  processing  [this  would  include  setting  up  the 
sentence  that  will  initiate  the  new  dialogue 
(that  is, the  request  sentence)] 

(spawn-request 

request-sentence 
enQ-outgoing 
: return-result 

# ' some-function-to-handle-request) 

may  do  more  processing  (if  needed) 

(funcall  conditional-suspend 
(create-Qtest 

Qstatus-incoming 
(list  dialog-name) ) 

# '  (lambda  () 

{continue  enQ-outgoing 

Qstatus-incoming 

deQ-incoming 
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conditional-suspend) ) ) ) ) ) 


2.  Integrating  the  Generic  Expert  and  a  Subsystem 

The  responsibility  of  the  subsystem  integrator  is  to  provide  the  functionality  that 
makes  a  generic  expert  an  instantiation  of  an  IMW  subsystem.  In  order  to  accomplish 
this  task  the  user  needs  to  be  able  to  (a)  access  the  information  contained  in  a  request, 
and  (b)  to  generate  a  response.  Since  PEL  is  the  language  of  communication  between 
IMW  subsystems,  both  requests  and  responses  will  take  the  form  of  PEL  sentences. 


2.1.  Accessing  the  Request  Sentence 

The  generic  expert  shell  supplies  functions  that  extract,  from  the  incoming  PEL 
sentence,  the  information  needed  by  a  subsystem  to  satisfy  the  request.  Por  example, 
similar  to  the  C-n-  version  of  the  generic  expert  shell,  the  lisp  version  provides  both  a 
sentence  iterator  and  a  feature  list  iterator. 

The  access  functions  may  be  divided  into  two  categories,  those  that  access  the  top 
level  elements  of  a  sentence,  and  those  that  access  the  elements  of  a  feature  list. 


2.1.1.  Accessing  the  Top  Level  Elements  of  the  Request  Sentence 

PoUowing  are  the  functions  that  allow  access  of  the  top  level  elements  of  a  sentence. 
Por  the  sake  of  explanation,  assume  that  FEL-sentence  is  an  object  of  type  sentence. 

(A)  sentence-iterator  returns  two  functions  that  may  be  used  to  iterate  through  the 
feature  lists  of  a  sentence.  The  first  function  always  returns  the  first  feature  list.  Each 
call  to  the  second  function  returns  the  next  feature  list.  When  the  list  is  exhausted,  :end 
is  returned. 

Por  example,  the  s-expression: 

(multiple-value-bind  (siter-first  siter-next) 
(sentence-iterator  FEL-sentence)  ) 

locally  binds  a  function  to  each  of  the  two  variables:  siter-first  and  sIter-next.  The  first 
feature  list  of  FEL-sentence  is  always  returned  by  siter-first,  and  siter-next  returns  the 
subsequent  feature  lists. 

(B)  The  form  (sentence-name  FEL-sentence)  will  return  the  dialogue  name  of 
FEL-sentence. 

(C)  The  form  (sentence-verb  FEL-sentence)  returns  the  verb  of  FEL-senfe«ce. 
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(D)  The  form  (sentence-from  FEL-sentence)  returns  the  name  of  the  expert  that 
originated  FEL-sentence. 


2.1.2.  Accessing  the  Elements  of  a  Feature  List 

Following  are  the  functions  that  provide  access  to  the  elements  of  a  feature  list  (i.e, 
the  attribute/value  pairs).  For  the  s^e  of  exposition,  assume  that /List  is  an  object  of 
tyipe  featurelist 

(A)  featureList-lterator  returns  two  functions  that  may  be  used  to  iterate  through  the 
feature  list's  attribute/ value  pairs.  The  first  function  always  returns  the  first 
attribute/value  pair  of  the  feature  list.  Each  call  to  flie  second  function  returns  the  next 
available  attribute/value  pair.  When  the  list  is  exhausted,  tend  is  returned. 

For  example,  the  s-expression: 

(multiple-value-bind  (fL_Iter- first  f L_Iter-next ) 

(featureList-lterator  fList)  ) 

binds  a  function  to  each  of  the  two  local  variables.  fLJter-first  returns  the  first 
attribute/value  pair  oi fList  and  fLJter-next  returns  the  next  available  attribute/ value 
pair  of  fList. 

(B)  The  form  (valueOfAttribute  fList  attribute-name)  will  retrieve,  from 
fList,  the  attribute/ value  pair  whose  attribute  is  equal  to  attribute-name. 

(C)  The  form  (typeOf  fList)  returns  the  feature  list  type  of /List.  In  other  words, 
typeOf  returns  the  value  of  the  attribute/value  pair  whose  attribute  is  the  symbol  TYPE. 


2.2.  Creating  the  Response 

For  each  request  received,  it  is  expected  that  the  subsystem  will  generate  a 
response.  In  order  to  facilitate  the  process,  a  set  of  functions  are  provided  that  construct 
and  modify  sentences  and  feature  lists. 


2.2.1.  Creating  and  Modifying  FEL  Sentences 

The  most  straight  forward  way  to  create  a  sentence  that  will  be  used  as  a  response 
to  a  request  is  to  evaluate  the  form: 

(funcall  (sentence-reply To  FEL-sentence)  symbol) 


where, 

(i)  FEL-sentence  is  an  object  of  type  sentence,  and 
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(ii)  symbol  is  an  object  of  type  keyword. 

FEL-sentence  is  the  sentence  that  initiated  the  request  for  which  the  response  is  being 
prepared,  symbol  is  either  a  verb,  or  the  tense  of  a  verb.  If  symbol  is  one  of  the 
recognized  verbs,  then  the  verb  of  the  newly  created  sentence  will  be  set  to  symbol  If 
symbol  is  a  legitimate  verb  tense^,  then  the  predicate  of  the  response  sentence  will  be  the 
verb  that  is  the  specified  inflected  form  of  FEL-sentenc^s  verb. 

For  example,  if  the  value  of  the  symbol,  FEL-sentence,  is: 

(:  offer 

((:name  :pl_l)  (:type  rmessage)  (:to  :hx)  (:from  :pl) ) ) 


then, 

(: offered 

((:name  :pl_l)  (:type  :message)  (:to  :pl)  (rfrom  :hx) ) ) 
would  be  the  sentence  created  by  evaluation  of  either  of  the  following  s-expressions: 
(funcall  (sentence-replyTo  FEL-sentence)  : offered) 

(funcall  (sentence-replyTo  FEL-sentence)  :past). 

From  the  preceding  example  it  should  be  noted  that  the  form: 

(funcall  (sentence-replyTo  FEL-sentence)  symbol) 

does  not  just  initialize  the  sentence's  verb.  A  feature  list  of  type  message  is  also  added  to 
the  response.  This  feature  list  contains  (a)  the  name  of  the  didogue^,  (b)  the  destination 
of  the  sentence^,  and  (c)  the  source  of  the  sentence^. 

If,  once  again,  the  value  of  the  symbol,  FEL-sentence,  is  the  request  sentence,  then 
the  destination  of  the  response  sentence  is  equal  to  the  result  of  evaluating  the  form, 
(sentence-from  FEL-sentence) .  The  source  of  the  response  is  set  to  the  expert 
that  received  FEL-sentence.  And  the  name  of  the  newly  created  sentence  and  FEL- 
sentence  are  identical.  That  is,  both  sentences  belong  to  the  same  dialogue. 

A  subsystem  integrator  is  provided  with  the  means  to  easily  access  the  name,  verb, 
source  and  destination  of  a  sentence.  The  following  functions  provide  that  access. 

They  all  take  an  object  of  type  sentence  as  an  argument.  Let  FEL-sentence  be  such  an 
object.  The  dialogue  name  is  obtained  via  evaluation  of  the  form: 

(sentence-name  FEL-sentence) . 


2.  T)^ically,  EEL  provides  four  tenses  for  each  verb:  present,  active,  past,  and  not. 

3.  The  name  of  a  dialogue  is  the  value  of  the  attribute  name ,  in  a  feature  list  of  type  message. 

4.  The  destination  of  a  sentence  is  the  value  of  the  attribute  to,  in  a  feature  list  of  type  message. 

5.  The  source  of  a  sentence  is  the  value  of  the  attribute  from,  in  a  feahme  list  of  type  message. 
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The  verb  of  the  sentence  is  obtained  via  evaluation  of  the  form:  ‘ 

(sentence-verb  PEL- sentence ) . 

The  source  of  the  sentence  is  obtained  via  evaluation  of  the  form: 

(sentence- from  FEL-sentence) . 

And  the  destination  of  the  sentence  is  provided  by  evaluation  of: 

(sentence-to  FEL-sentence). 

On  rare  occasions  the  subsystem  integrator  may  be  constructing  a  sentence  whose 
verb,  name,  destination,  and/or  source  are  not  appropriate.  When  this  situation  arises, 
self  may  be  used  on  any  of  the  preceding  four  forms  to  alter  their  values.  For  example, 
to  set  the  verb  of  FEL-sentence  to  inotoffered,  the  form: 

(setf  (sentence -verb  FEL-sentence)  :notoffered) 

needs  to  be  evaluated.  If  the  name,  source,  or  destination  of  a  sentence  is  changed,  then 
this  new  information  is  reflected  in  the  sentence's  message  feature  list 


2.2.2.  Creating  and  Modifying  Feahire  Lists 

Once  a  request  sentence  has  been  created,  it  typically  needs  to  filled  with  feature 
lists  that  comprise  the  response.  The  Lisp  based  generic  expert  provides  functions  to 
assist  in  the  initial  aeation,  and  subsequent  modification,  of  feature  lists. 

The  function  create-featureList  returns  an  object  of  type  featureList  create-featureList 
requires  no  arguments. 

In  order  to  add  an  attribute/value  pair  to  the  front  of  a  feature  list  the  expert 
specific  code  must  include  an  s-expression  of  the  form: 

(funcall  (featureList-include  fL)  attribute  value) 


where 

(i) /L  is  an  object  of  type  featureList, 

(ii)  attribute  is  the  name  of  an  attribute,  and 

Gii)  value  is  the  value  that  is  to  be  associated  with  attribute. 

If  it  is  desired  order  to  add  an  attribute/value  pair  to  the  back  of  a  feature  list  the 
expert  specific  code  must  evaluate  an  s-expression  of  the  form: 

(funcall  (featureList-append  fL)  attribute  value) 
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where 

(i)  fL  is  an  object  of  type  featureList, 

(ii)  attribute  is  the  name  of  an  attribute,  and 

(iii)  value  is  the  value  that  is  to  be  associated  with  attribute. 

A  note  of  warning;  a  feature  list  created  by  expert  specific  code  needs  to  contain 
both  an  attribute/ value  pair  of  type  NAME  and  an  attribute/ value  pair  of  type  TYPE. 


2.2.3.  Adding  Feature  Lists  to  Sentences 

Once  the  feature  list  is  complete  (that  is,  all  of  the  attribute/  value  pairs  have  been 
added),  it  may  be  added  to  the  response  sentence.  The  subsystem  integrator  has  the 
option  of  adding  the  feature  list  at  the  beginning  of  the  sentence  or  at  the  end. 

Adding  a  feature  list  at  the  beginning  of  an  FEL  sentence  is  accomplished  by 
evaluation  of  an  s-expression  of  the  form: 

(funcall  (sentence- include  reply)  fL) 


where 

(i)  reply  is  an  object  of  type  sentence,  and 

(ii)  ft  is  an  object  of  type  featureList. 

To  add  a  feature  list  at  the  end  of  an  FEL  sentence,  the  following  form  must  be 
evaluated: 


(funcall  (sentence-append  reply)  fL) 


3.  Symbols  in  an  FEL  Sentence 

Up  to  this  point,  it  has  not  been  explicitly  stated  as  to  the  package  in  which  the 
symbols  of  an  FEL  sentence  should  reside.  IS  all  of  the  components  of  an  expert  weie  to 
be  interned  in  the  same  package,  and  the  current  package  never  deviated  from  that 
package,  then  problems  would  never  arise.  However,  this  is  an  unreasonable 
assumption.  For  example,  the  application  specific  code  for  the  Human  Interface  is  read 
into  the  CRL-USER  package  while  the  generic  expert  component  is  read  into  the 
GENERIC-EXPERT  package. 

To  alleviate  any  potential  problems,  all  of  the  symbols  in  an  FEL  sentence  must  be 
interned  in  the  KEYWORD  package.  This  will  ensure  that  the  symbols  of  an  FEL 
sentence  that  have  the  same  print  name  will  be  EQ. 

The  implications  for  the  subsystem  integrator  are  two.  First,  all  symbols  used  in  the 
construction  of  an  FEL  sentence  must  reside  in  the  KEYWORD  package.  For  example, 
when  adding  the  attribute/value  pair  (name  foo)  to  the  feature  list,/L,  the  integrator 
should  use  the  form: 
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(funcall  (featureList-include  fL)  :name  :foo) - 

Secondly,  when  comparing  a  symbol  against  a  symbol  from  eii  FEL  sentence  the 
integrator  should  be  cognizant  of  the  fact  that  the  symbol  from  the  sentence  will  be 
interned  in  the  KEYWORD  package.  For  example,  to  obtain  the  value  of  the  attribute 
name  from  the  feature  list,/L,  use  3te  form: 

(valueOf  Attribute  fL  tname) 

Why  use  the  KEYWORD  package?  The  S5nnbols  of  an  FEL  sentence  are  only  to  be 
used  as  symbolic  constants.  That  is,  the  value,  definition,  or  properties  bound  to  the 
symbols  are  irrelevant.  Common  Lisp  provides  the  KEYWORD  package  for  exactly  this 
purpose. 


4.  Interface  Between  Generic  Expert  and  Subsystem  Specific  Code 

To  ease  the  process  of  integration,  an  outline  of  a  function  is  provided  for  the  user. 
This  ftmction,  ex,  provides  an  interface  between  the  subsystem  specific  code  and  the 
generic  expert  shell.  The  subsystem  integrator  need  not  worry  about  any  of  the 
implementation  details  below  this  function. 

Brief  comments  are  interspersed  throughout  the  function  definition  that  follows. 
Some  of  the  comments  are  hints  as  to  the  placement  of  subsystem  specific  code. 


(in-package  (find-package  ' expert -package) ) 
(use-package  (find-package  ’generic-expert)) 


(defun  ex  (enQ-outgoing 

Qstatus-incoming 

deQ-incoming 

conditional-suspend) 

(declare 

(function  ex  (symbol  symbol  symbol  symbol)  t)) 

(let  (  (FEL-sentence  (funcall  deQ-incoming))  )  ;  Dequeue  the  request, 

(declare 

(type  sentence  FEL-sentence) ) 

(case  (sentence-verb  FEL-sentence) 

; ;  The  subsystem  integrator  should  Insert  clauses  for  the 
; ;  verbs  that  the  expert  is  expected  to  handle . 

;;  For  example,  let  :plan  be  such  a  verb. 

( :plan 

;;  Create  iterators  for  the  request  sentence, 
(multiple-value-bind  (siter-first  siter-next) 
(sentence-iterator  FEL-sentence) 
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;;  Cycle  through  the  feature  lists. 

(do  (  (fList  (funcall  siter-first)  (funcall  siter-next))  ) 

{ (eq  fList  rend) ) 

(let  (  (fList-type  (typeOf  fList) )  ;  (3et  feature  list  type 
(reply  (funcall 

( sentence-rep lyTo  FEL-sentence) 
rplanned) )  ) 

(case  fList-type 

;;  key-symbol  is  application  dependent.  Normally, 

; ;  there  will  be  a  clause  for  each  feature  list  type 
; ;  that  the  IMN  subsystem  is  required  to  handle . 
(key-symbol 

;;  A  subsystem  integrator  may  either  use  the 
;;  function  valueOf  Attribute  to  obtain  the  value 
;;  of  an  attribute,  or  use  the  iterator  functions, 
;;  £L_Iter-£irst  and  £L_Iter-next,  to  step  through 
;;  the  feature  list. 

(multiple-value-bind  (fL_Iter-first  fL_Iter-next) 
(featureList-Iterator  fList) 

(let  (  (fL  (create-featureList) )  ) 

(declare 

(type  featureList  fL) ) 

; ;  Expert  dependent  code  should  corpute 
;;  the  appropriate  attribute/value  pairs 
;;  and  add  them  to  £L. 

(funcall  (featureList-include  fL) 
attribute  value) 

;;  Once  the  feature  list  is  conplete,  add 
;;  it  to  the  sentence  to  be  sent  as  a  reply. 

(funcall  (sentence-include  reply)  fL) ) ) ) 
(otherwise 

;;  Application  specific  error  handling. 

))))))))) 

The  following  subsections  provide  information  about  miscellaneous  topics  that 
affect  the  writing  of  an  subsystem's  initial  function  (such  as  the  example,  ex). 


4.1.  Explicit  Use  of  Packages 

The  Lisp-based  version  of  the  generic  expert  makes  explicit  use  of  packages. 
Normally,  the  symbols  of  a  Lisp-based  expert  will  be  interned  in  a  package  specific  to 
the  expert.  In  the  statement: 
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(in-package  (find-package  'expert-package)) 

expert-package  should  be  the  package  utilized  by  the  expert. 

The  generic  expert  shell  resides  in  the  GENERIC-EXPERT  package  and  exports  the 
symbols  that  have  meaning  for  the  subsystem  integrator.  Hence,  the  use.of  the 
statement: 

(use-package  (find-package  'generic-expert)). 

Evaluation  of  this  form  imports  the  symbols  from  the  generic  expert  into  the  package 
used  by  the  expert. 


4.2.  Naming  the  Initial  Fxmction  of  an  Expert 

When  an  EEL  sentence  is  delivered  to  an  expert,  the  generic  expert  shell  determines 
if  it  is  for  an  existing  dialogue,  or  if  the  sentence  initiates  a  new  dialogue.  If  the 
sentence  is  to  initiate  a  new  dialogue,  the  generic  expert  calls  the  function  provided  by 
the  subsystem  integrator,  ex  was  just  such  a  function. 

A  convention  exists  for  the  naming  of  the  initial  function.  The  name  of  the  function 
is  the  abbreviation  of  the  expert.  For  example,  the  name  of  the  Planner's  initial  function 
would  be  PL 


4.3.  Arguments  Passed  to  the  Expert’s  Initial  Function 

Four  arguments  are  passed  by  the  generic  expert  shell  to  the  initial  function.  They 
are  as  follows: 

(a)  enQ-outgoing, 

(b)  Qstatus-incoming, 

(c)  deQ-incoming,  and 

(d)  conditional-suspend. 

Associated  with  each  expert  are  two  queues.  One  is  a  queue  for  incoming  sentences 
and  the  other  is  a  queue  for  outgoing  sentences  (see  Figure  3). 
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Eihemst 


Outgoing  t  I  Incoming 


The  argument  enQ-outgoing  is  a  variable  whose  value  is  a  function  that  may  be 
called  to  send  out  an  PEL  sentence.  For  example,  if  reply  is  an  object  of  type  sentence 
and  a  valid  FEL  sentence,  then  the  form: 

(funcall  enQ-outgoing  reply) 
will  place  reply  on  the  output  queue. 

Incoming  sentences  for  an  expert  are  placed  on  the  appropriate  queue  by  the 
generic  expert  shell.  Qstatus-incoming  gives  access  to  a  function  that  allows  the 
integrator  to  programmatically  check  if  there  are  any  FEL  sentences  on  the  incoming 
queue.  Qstatus-incoming  returns  :empty  if  the  queue  is  empty,  and  :non-empty  if  it  is  not. 

Of  course,  just  knowing  that  there  is  a  sentence  on  the  queue  is  not  much  help. 
There  needs  to  be  a  way  of  obtaining  the  sentence  from  the  queue.  deQ-incoming  serves 
that  function.  For  example,  the  code  segment 

(let  (  (FEL-sentence  (funcall  deQ-incoming) )  ) 

...  ) 

will  pop  the  next  entry  off  of  the  queue  and  bind  FEL-sentence  to  it.  If  the  queue 
contains  no  entries,  then  deQ-incoming  returns  -.empty. 

conditional-suspend  is  used  when  an  expert  needs  to  suspend  execution  until  a 
particular  event  occurs.  The  details  of  comitional-suspend  are  described  in  section 
1. 2.1.2. 
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4.4.  Branch  on  Verb  of  PEL  Sentence 

Typically,  an  expert  must  be  able  to  handle  more  than  one  verb.  For  example,  the 
initial  function  of  the  Plan  Manager  is  currenfly  able  to  process  tlte  verbs  ‘.execute  and 
‘.receive.  The  example  initial  function,  ex,  employs  a  case  statement  to  branch  on  the  verb 
of  the  incoming  FEL  sentence.  For  example,  following  is  the  outline  of  the  case 
statement  used  by  the  Plan  Manager  to  branch  on  the  verb  of  the  incoming  sentence, 
FEL-sentence. 

(case  (sentence- verb  FEL-sentence) 

(: execute 

...  ) 

( : receive 

...  ) 

(otherwise 

(format  *terminal-io*  "-SUnexpected  Verb~%") ) ) 


5.  Creating  an  Instantiation  of  a  Lisp-Based  Expert 

Once  the  user  has  provided  the  functionality  required  by  a  particular  subsystem,  an 
instantiation  of  that  expert  is  accomplished  by  evaluation  of  the  function  expert .  The 
only  required  argument  is  the  name  of  the  expert  which  the  instantiation  will  represent. 
For  example,  for  an  instantiation  of  the  Planner  the  name  would  be  PL. 

The  generic  interface  provides  two  interfaces  to  an  expert:  (a)  a  network  interface, 
and  (b)  a  terminal  interface.  Hie  user,  at  the  time  of  instantiation,  specifies  which 
interfaces  will  be  made  available  to  the  expert.  This  i  accomplished  through  the  use  of 
keyword  options.  That  is,  for  each  of  the  interfaces  there  is  a  keyword  option  which 
determines  if  the  interface  will  be  operable  during  the  current  instantiation.  The 
keyword  option  for  the  network  interface  is,  metwork-medium ,  and  for  the  terminal 
interface,  ‘.terminal-medium.  Either,  or  both,  of  these  interfaces  may  be  provided  to  the 
user. 


6.  Network  Interface 

The  network  interface  is  the  default  interface.  If  the  network  interface  is  not 
desired,  then  the  keyword  option  metwork-medium  should  be  given  the  value  of  nil. 

Before  creating  a  Lisp-based  IMW  subsystem  there  is  a  matter  concerning  network 
communication  that  needs  to  be  discussed.  The  network  communication  software 
currently  requires  a  file,  Bascom.db ,  that  lists  the  experts  in  the  IMW  system  and 
specifies  over  which  ports  they  communicate.  If  die  network  communication  software 
is  to  be  used  then  this  file  must  be  properly  configured  (see  documentation  on 
BASCOM).  As  provided,  the  file  lists  two  experts:  PL  and  DUMMY.  This  may  be 
changed  by  editing  BascomAh.  With  the  current  file  organization,  this  file  is  located  in 
the  Generic-ExpertCommunication.Low-Level;  directory. 
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7.  Tenninal  Interface 

The  default  action  of  the  generic  expert  is  also  to  provide  a  terminal  interface.  If  the 
tenninal  interface  is  not  desired,  the  keyword  option  ‘.terminal-medium  should  be  given  a 
value  of  nil. 

Why  prr‘''/ide  a  terminal  interface?  An  IMW  subsystem  may  be  viewed  as  a  filter; 
an  PEL  sentence  is  input,  some  processing  is  performed,  and  then  an  PEL  sentence  is 
output.  E)uring  development  and  testing,  it  is  occasionally  desirable  to  have  total 
control  over  the  input  to  the  subsystem.  Then,  after  the  processing  is  complete  it  would 
be  nice  to  easily  view  the  output.  As  mentioned  in  the  preceding  section,  the  experts 
commimicate  with  each  other  via  the  ethemet.  This  process  of  network  communication 
implies  the  existence  of  at  least  two  fimctioning  IMW  subsystems.  On  occasion,  this 
complicates  the  process  of  development.  Consequently,  a  terminal  interface  is  provided 
that  will  allow  an  instantiation  of  an  expert  to  function  stand-alone.  That  is,  the  input  is 
provided  to  the  expert  via  the  terminal  interface  and  the  output  from  the  expert  is 
displayed  on  the  terminal  window. 

In  order  to  obtain  a  stand-alone  configuration,  enter  the  command: 

(generic-expert  expert-name 

: network-medium  nil) 

During  evaluation  of  the  above  function  call,  the  user  will  be  required  to  provide  the 
upper-left  and  bottom-right  hand  comers  of  the  interface  window.  The  comers  are 
chosen  via  the  mouse. 

Initially,  the  interface  window  is  not  visible.  When  it  is  needed  the  window  needs 
to  be  selected.  This  may  be  accomplished  by  bringing  up  the  Explorer  System  Menu. 

In  the  WINDOWS  column  click  on  the  entry  named  Select.  This  will  bring  up  a  menu 
that  will  list  the  currently  available  windows.  One  of  those  will  have  the  name  of  the 
expert  (e.g.,  PL),  dick  on  that  name.  This  will  bring  up  the  interface  window.  At  this 
point,  PEL  sentences  may  be  input  to  the  ex'pert  for  processing.  That  is,  the  sentence 
may  be  typed  into  the  window.  After  processing,  the  resulting  PEL  sentence  will  be 
displayed  in  the  window. 

Don't  be  misled  by  the  above  discussion  of  a  stand-alone  subsystem.  It  is  also 
possible  to  have  both  a  terminal  interface  and  a  network  interface  for  an  expert.  In  that 
way  you  can  provide  input  to  one  expert  and  have  the  output  sent  along  to  another 
expert. 

As  an  example,  let's  assume  that  we  have  two  experts:  a  holding  expert  (HX)  and  a 
sensing  expert  (SX).  If  the  coimnand: 
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(OFFER 

(  (NAME  SX_OFFER_l) 
(TYPE  MESSAGE) 

(TO  HX) 

(FROM  SX) 

(MEDIUM  (tNETWORK))  ) 
(  (NAME  SX_SELECT_1) 
(TYPE  SELECT) 
(FIXTURES  MAX)  )) 


is  entered  into  the  tenninal  interface  for  the  HX  subsystem,  it  will  receive  the  FEL 
sentence  as  if  the  source  were  the  SX  subsystem.  Therefore,  the  reply  generated  by  HX 
will  be  sent  over  the  network  to  SX. 

In  the  above  example,  there  is  one  detail  worth  noting;  that  is,  the  attribute/value 
pair  (MEDIUM  (:NETWORK))  in  the  feature  list  of  type  MESSAGE.  In  the  current 
implementation  of  the  generic  expert,  the  medium  over  which  a  reply  will  be  sent 
defaults  to  the  medium  over  which  the  request  was  received.  In  odier  words,  if  the 
request  comes  in  over  the  network  the  reply  goes  out  over  the  network  and  similarly  for 
the  terminal  interface.  The  attribute  MEDIUM  provides  a  method  for  overriding  the 
default.  Hence,  if  a  sentence  is  input  from  the  terminal  interface,  but  it  is  desired  that 
the  response  go  out  over  the  network  then  that  can  be  accomplished.  It  is  also  possible 
to  have  a  response  go  out  over  both  mediums.  A  value  of  (:NETWORK  :TERMNAL) 
for  the  attribute  MEDIUM  will  send  the  reply  out  over  both. 


8.  Setting  up  the  Generic  Expert  on  the  Explorer 

The  files  that  define  the  Lisp  based  generic  expert  may  be  obtained  by  tape  or  by 
copying  the  files  from  the  directory  Generic-Expert  on  the  machine  kafka.imw.ri.cmu.edu. 

i)  Copy  the  files  into  a  directory  named  Generic-Expert  on  your  machine.  All  is  not  lost 
if  some  reason  exists  that  prevents  the  use  of  a  directory  by  that  name.  The  files  may  be 
loaded  into  a  directory  of  your  choice.  However,  by  not  using  the  default,  some 
additional  work  is  required.  After  the  files  are  copied  into  a  directory,  the  file  Generic- 
Expert. Translations  must  be  edited  to  reflect  the  actual  location  of  the  files.  It  should  be 
noted  that  the  Generic-Expert. Translations  file  is  not  required  if  a  Generic-Expert  entry, 
with  the  appropriate  translations,  is  added  to  the  network  namespace. 

ii)  Move  the  files  Generic-Expert.System  and  Generic-Expert.Translations  into  the  Site 
directory. 

iii)  From  a  Lisp  Listener,  evaluate  the  command: 

(make-system  'generic-expert  ; compile  : noconfirm). 

This  will  load  the  Lisp  based  generic  expert  skeleton  into  the  environment. 
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9.  Glossary  of  Functions  for  Lisp-based  Generic  Expert 

(make-system  'generic-expert  : compile  : noconfirm) 

Install  the  Lisp-based  generic  expert  on  a  TI  Explorer.  This  assumes  that 
the  source  code  exists  on  the  machine  in  question. 


(gG:e:}q5ert  'XX) 

Instantiate  an  expert.  XX  is  tlte  initial  function  for  the  expert.  This 
ftmction  name  should  also  be  the  two  letter  abbreviation  of  the  expert. 

For  example,  the  initial  function  for  the  Planner  would  be  PL.  The  default 
for  the  function  gexxpert  is  to  provide  a  terminal  and  network  interface. 

The  symbol  expert  is  exported  by  the  GENERIC-EXPERT  package,  so  if  the 
user  executes  the  form: 

(use-package  (find-package  'generic-expert)) 

then  access  may  be  gained  to  ge:expert  without  the  annoying  package 
prefix  (that  is,  ge:). 

Following  is  the  basic  outline  of  the  initial  function  for  an  expert.  In  this 
example,  the  expert  is  named  XX. 

(defun  XX  (enQ-outgoing 

Qstatus-incoming 

deQ-incoming 

conditional-suspend) 

(declare 

(function  XX  (symbol  symbol  symbol  symbol)  t) ) 

(let  ( (FEL-sentence  (f uncall  deQ-incoming) )  ) 

(declare 

(type  sentence  FEL-sentence) ) 

(case  (sentence-verb  FEL-sentence) 

;*  Clauses  for  the  verbs  that  expert  XX  is 
;*  expected  to  handle 

(otherwise 

;*  implication  specific  error  handling 

))) 


(funcall  enQ-outgoing  FEL-sentence) 
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enQ-outgoing  takes  one  argument,  an  object  of  type  sentence.  FEL-sentence 
is  placed  on  the  queue  which  is  read  for  output.  enQ-outgoing  is  not  a 
global  fimction.  It  is  one  of  the  arguments  passed  to  the  expert's  initial 
function. 


(f uncall  Qstatus -incoming) 

Returns  '.non-empty  when  the  incoming  queue  has  at  least  one  unread 
object  of  type  sentence  on  it.  :empty  is  returned  when  the  queue  is  empty. 
Qstatus-incoming  is  not  a  global  function.  It  is  one  of  the  arguments  passed 
to  the  expert's  initial  function. 


(f uncall  deQ- incoming) 

Returns  an  object  of  type  sentence.  PEL  sentences  placed  on  this  queue  are 
to  be  read  as  input.  deQ-incoming  is  not  a  global  function.  It  is  one  of  the 
arguments  passed  to  the  expert's  initial  function. 


(f uncall  conditional- suspend  test  fen) 

conditional-suspend  takes  two  arguments.  The  first  is  a  test.  When  it 
evaluates  to  non-nil,  the  second  argument,  a  function,  is  executed. 
conditional-suspend  is  not  a  global  Action.  It  is  one  of  the  arguments 
passed  to  the  expert's  initial  function. 


(create-Qtest  Qstatus  dialogNames) 

Returns  a  function  that  queries  the  queue  whose  status  is  obtained  via  the 
function  Qstatus.  The  query  is  determined  by  the  value  of  dialogNames, 
which  should  be  a  list  of  dialogue  names.  That  is,  the  returned  function 
will  rehim  non-nil  if  sentences  exist  on  the  queue  that  are  assodated  with 
the  names  in  dialogNames;  otherwise  nil  is  returned.  Typically,  create-Qtest 
is  used  in  conjunction  with  conditional-suspend. 


(spavm-request  FEL-sentence  enQ-outgoing  disposition  fen) 

This  function  initiates  a  new  dialogue.  It  requires  four  arguments. 

FEL-sentence  is  the  sentence  that  will  initiate  the  dialo^e  with  the 
designated  expert.  The  spawn  slot  of  a  sentence  object  is  normally  used  to 
CTeate  this  new  sentence. 
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enQ-outgoing  is  the  function  used  to  queue  the  sentence  for  output.  This 
function  is  an  argument  passed  to  the  initial  function  of  the  expert. 

disposition  is  the  disposition  of  the  result  of  the  spawned  dialogue. 
Currently,  this  may  be  one  of  two  values,  either  iretum-result  or 
'.independent  A  disposition  of  '.return-result  signifies  that  the  originating 
dialogue  expects  to  have  access  to  the  final  result,  which  should  be  an  PEL 
sentence.  In  order  to  gain  access  to  this  PEL  sentence,  the  spawned 
dialogue  should  ensure  that,  upon  termination,  this  sentence  is  the  value 
returned,  '.independent  signifies  that  the  spawned  dialogue  may  proceed 
independently  of  the  spawner. 

fen  is  the  function  that  will  handle  the  spawned  dialogue. 


(create-featureList) 

Returns  an  object  of  type  featureList. 


The  next  three  functions  take  an  object  of  type  featureList  as  an  argument.  Let  fList 
be  such  an  object. 


(featureList-iterator  fList) 

Returns  two  functions  that  may  be  used  to  iterate  through  the 
attribute /value  pairs  of  a  feature  list.  The  first  function  always  returns  the 
first  attribute/vdue  pair  of  the  feature  list.  Each  call  to  the  second 
function  returns  the  next  attribute/value  pair.  When  the  list  is  exhausted 
:end  is  returned. 


(funcall  (featureList-append  fList)  attribute  value) 

Associate  value  with  attribute  and  add  this  attribute/value  pair  at  the  end 
of  the  feature  list's  attribute/value  pairs. 


(funcall  (featureList-include  fList)  attribute  value) 

Associate  value  with  attribute  and  add  this  attribute/value  pair  at  the 
beginning  of  the  feature  list's  attribute/value  pairs. 


(funcall  (featureList-updat©  fList)  attribute  value) 

Pind  the  attribute/value  pair  in  fList  with  an  attribute  equal  to  attribute. 
Change  the  value  of  this  pair  to  value. 
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The  following  functions  take  an  object  of  type  sentence  as  an  argument.  Let  FEL- 
sentence  be  such  an  object. 


(sentence-iterator  FEL-sentence) 

Returns  two  functions  that  may  be  used  to  iterate  through  the  feature  lists 
of  the  sentence.  The  first  function  always  returns  the  first  feature  list 
Each  call  to  the  second  function  returns  the  next  feature  list  When  the 
list  is  exhausted  :end  is  returned, 

It  should  be  noted  that  the  feature  list  containing  the  attribute/value  pair 
(type  message)  is  not  returned  by  either  of  the  iterators.  The 
information  that  is  contained  in  that  feature  list  is  to  be  obtained  more 
directly.  For  example,  sentence-to  returns  the  destination. 


(sentence-name  FEL-sentence) 

Returns  the  dialogue  name  of  FEL-sentence.  set/ may  be  used  on  this  form 
to  change  the  value. 


(sentence-verb  FEL-sentence) 

Returns  the  verb  of  FEL-sentence.  setf  may  be  used  on  this  form  to  change 
the  value. 


(sentence-from  FEL-sentence) 

Returns  the  source  of  FEL-sentence.  setf  may  be  used  on  this  form  to 
change  the  value. 


(sentence-to  FEL-sentence) 

Rehims  the  destination  of  FEL-sentence.  setf  may  be  used  on  this  form  to 
change  the  value. 


(sentence-medium  FEL-sentence) 

Returns  a  list  whose  elements  are  the  medium  of  FEL-sentence.  setf  may  be 
used  on  this  form  to  change  the  value. 
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If  FEL-sentence  is  a  sentence  to  be  output,  then  the  value  of  the  above  form 
gives  the  media  over  which  this  sentence  will  be  sent.  For  example,  if 
evaluation  of  the  form: 

(sentence-medium  FEL-sentence) 
produced  the  result: 

(:  network  :teminal); 

then,  when  output,  the  FEL-sentence  would  be  sent  to  both  the  network 
handler  and  the  terminal  handler.  If  FEL-sentence  is  a  sentence  that  was 
sent  to  the  expert,  then  the  form,  (sentence-medium  FEL-sentence), 
gives  the  medium  over  which  the  sentence  arrived.  Normally,  the 
subsystem  integrator  need  not  worry  about  the  input  and/or  output 
media. 


(funcall  (sentence-include  FEL-sentence)  feature-list) 

Include  feature-list  in  the  sentence  FEL-sentence,  -where  feature-list  is  an 
object  of  type  featureList. 


(funcall  (sentence-replyTo  FEL-sentence)  verb-or-tense) 

Returns  an  object  of  type  sentence.  The  verb  of  the  newly  created  sentence 
is  determined  by  the  value  of  the  symbol  verb-or-tense.  If  the  value  of  verb- 
or-tense  is  one  of  the  recognized  verbs,  ti\en  the  verb  of  the  sentence  is 
simply  the  value  of  verb-or-tense.  If  verb-or-tense  is  a  legitimate  verb  tense, 
then  the  predicate  of  the  response  sentence  will  be  the  verb  that  is  the 
specified  inflected  form  of  FEL-sentence' s  verb.  The  destination  of  the 
sentence  is  equal  to  (sentence- from  FEL-sentence).  The  source  of 
the  sentence  is  set  to  the  expert  that  received  FEL-sentence.  The  name  of 
the  aeated  sentence  and  FEL-sentence  are  identical. 


(funcall  (sentence-spawn  FEL-sentence)  verb) 

Returns  an  object  of  type  sentence.  The  verb  of  the  newly  created  sentence 
has  been  set  to  verb.  The  source  of  the  sentence  is  set  to  the  expert  that 
received  FEL-sentence.  The  destination  of  the  sentence  is  not  set.  A  unique 
symbol  is  created  for  the  name  of  the  sentence. 


The  next  two  functions  take  an  attribute/value  pair  as  an  argument.  An 
attribute/ value  pair  is  a  list  of  two  elements.  The  first  element  is  a  symbol.  The  second 
element  may  be  one  of  four  types:  a  symbol,  a  number,  a  string,  or  a  list.  In  the 


135 


Carnegie  Mellon  University 


Generic  Expert  G-isp-Based) 


examples,  let  pair  be  an  attribute/ value  pair. 


(attributeOf  pair) 

Returns  the  attribute  oipair. 


(valueOf  pair) 

Returns  the  value  of  pair. 


These  last  functions  take  an  object  of  type  featureList  as  an  argument.  Let  fList  be 
such  an  object. 


(nameOf  fList) 

Return  the  value  of  the  attribute/value  pair  whose  attribute  is  the  s)nnbol 


NAME. 


(typeOf  fList) 

Return  the  value  of  the  attribute/ value  pair  whose  attribute  is  the  symbol 
TYPE. 

(valueOfAttribute  fList  attribute) 

Return  the  value  of  the  attribute  denoted  by  attribute. 
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